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ABSTRACT 


This research assesses the impact of synchronous (real-time), text-based chat on 
military command and control (C2) processes. Chat use among the services, particularly 
among joint forces, has evolved in ad hoc fashion to fill gaps in currently fielded C2 
systems. This growth-by-improvisation inhibits clear definition of the underlying 
requirements: precisely what C2 deficiencies are being addressed by text-based chat 
tools? Or, from a bottom-up perspective: what capabilities do text-based chat tools bring 
to the war fighter? In this study we employ a broad set of use-cases to further refine why 
operators use chat based on how they apply chat to their specific combat problems. 
These use cases include ongoing combat operations in ENDURING FREEDOM, 
counter-insurgency operations in IRAQI FREEDOM, and disaster relief operations with 
Joint Task Force - Katrina. The focus of this study is on establishing operators’ 
perceived requirements in light of the current capabilities delivered by the existing text- 
based chat tools. From these “reverse-engineered” requirements we propose future work 
to establish these communication capabilities in the next-generation C2 systems. 
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I. INTRODUCTION 

A. PROBLEM STATEMENT 

1. Description 

Communication is the essence of command and control (C2), and the availability 
of real-time, text-based communications tools has led to a proliferation of ad hoc 
“solutions” for the warfighter. Currently within the services, every command appears to 
have its own preferred text-based chat client. While these solutions fill short term 
requirements, they usually miss the mark of joint interoperability. Lack of a standardized 
text chat tool for C2 has led to confusion and an inability to interoperate. No official 
text-based chat requirements document exists for any of the services nor is there an 
official joint chat requirements document. Further, there is no official support for text- 
based chat from the services’ program offices. In effect, within the U.S military there is a 
tool used extensively for C2 with no official requirements, no official support, and no 
official sponsorship. 

This thesis first assesses the impact of synchronous (real-time), text-based chat on 
military C2 processes. Operational chat usage is documented across the warfighting 
functions and the full spectrum of military operations with a brief selection of use cases. 
The current trend in chat research focuses on the technical aspects of chat based on 
anecdotal evidence, both of which obscure development of a coherent problem statement. 
This research consolidates specific cases of chat use to better develop insight into the 
problem, catalog capability gaps, and generate high-level requirements. 

There is risk associated with various chat tools and protocols. These technical 
risks are well documented by organizations like the Defense Information Systems 
Agency (DISA). In this paper, we assess not only technical risks, but other risks that are 
very difficult to quantify, like those related to organization, human factors, doctrine, and 
perhaps most interestingly, the impact of chat use on other C2 methods. 

We finish with a framework for documenting current and developing future high- 
level chat requirements. These high-level requirements decompose the chat problem to a 
level that users, engineers, and managers alike can use and understand. From this 
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common understanding all stakeholders can work together to develop a set of combined 
and joint, text-based chat requirements for the next-generation C2 systems. 

2. Background 

Modern ehat tools allow multiple, coneurrent users real-time partieipation in 
multiple chat channels (ehat rooms). The eonversations within these channels are 
referred to as threads. The use of elient-server arehitecture provides the ability to scale a 
population of users from a few loeally to thousands globally. Internet Relay Chat (IRC) 
is one of the most widely used ehat protocols for military C2 (Boettcher 2005; Duffy 
2005). This study eonsiders chat usage regardless of type, whether chat specific tools 
like mIRC or Mierosoft Chat (MS Chat) or embedded chat functionality found in many 
C2 systems and eollaborative suites like InfoWorkSpace (IWS). 

Chat use by the military grew rapidly during Operation Enduring Freedom (OEF) 
and Operation Iraqi Freedom (OIF). Not only did chat usage grow on its own, we saw 
chat usage grow to supplement (or in some eases replace) other C2 systems. The 
experienees of the United State Navy and the United States Central Command 
(USCENTCOM) illustrate this. 

Early during OEF there was one IRC server in the Navy’s Fifth Fleet that 
averaged 300 concurrent chat users (Banerjee 2005). Chat use soon overcame capaeity 
and a seeond IRC server was installed in Fifth Fleet supporting approximately 500 
eoneurrent users (Banerjee 2005). Chat use grew drastically during OIF and two more 
IRC servers were installed, bringing the total to four servers supporting approximately 
2500-3000 coneurrent users in 350-400 ehat ehannels (Banerjee 2005; Heaeox, Moore, 
Morrison, and Yturralde 2004). Figure 1 shows the number of chat users and chat rooms 
on the Fifth Fleet servers by date from buildup through the start of combat operations. 
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Figure 1. IRC use prior to and during OIF; bps/user = bits per second per user (From; 

Bentrup, Banerjee, Baldwin, and Kimble 2005) 

Prior to OIF, USCENTCOM used the Defense Collaborative Tool Suite (DCTS) 
chat programs during exercises in Saudi Arabia; however, DCTS provided inadequate 
chat capability (no multiple room support) and USCENTCOM J6 made the switch to 
IWS (Jara and Lisowski 2003). The bandwidth requirements of chat with IWS created 
latency problems and USCENTCOM switched to the US Naval Eorces Central 
Command’s (USNAVCENT) four IRC servers in Bahrain, which continue supporting all 
areas of operations (Banerjee 2005; Jara and Lisowski 2003). Currently servers at 
USNAVCENT, A1 Udeid Airbase in Qatar, Headquarters USCENTCOM, and DISA 
support the following chat clients; mIRC, MS Chat, JABBER, and Internet Explorer Web 
Browser clients (Moore 2005). 

Users rapidly realized text chat was a mission essential C2 tool and discussion 
grew about the lack of official requirements, official support, and official sponsorship. 
Within the Department of the Navy, the Navy’s program office. Space and Naval 
Warfare Command (SPAWAR) reacted first. In response to the Navy’s text chat needs. 
Joint Distributed Command and Control Technologies, SPAWAR Systems Center San 
Diego (SSC-SD) hosted the 1st Annual Internet Relay Chat Conference in 2004. All four 
services, numerous Combatant Commands (COCOMs), and Other Government Agencies 

(OGAs) attended. The conference’s purpose was to identify chat users and provide 
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support to them throughout the Department of Defense (DOD). While foeused on IRC 
protocol-based chat tools, this conference supported users of all chat tools and discussed 
emerging technologies and the way forward within DOD. The 2nd Annual IRC 
Conference was held in June 2005 and was again attended by all four services, numerous 
COCOMs, and OGAs. 

During the June 2005 conference. Joint Distributed Command and Control 
Technologies SSC-SD was tasked with developing the joint chat requirements for a Joint 
Resource Oversight Council (JROC) package by Joint Chiefs of Staff J-6 (JCS-J6) and 
Office of the Assistant Secretary of Defense for Networks and Information Integration 
(ASD (Nil)). This research is part of that effort. 

3. Research Questions 

This thesis addressed four research questions: 

a. How is chat used across the services and warlighting functions? 

b. Why is chat used across the services and warlighting functions? 

c. What risks are associated with chat use? 

d. What are the high level chat requirements? 

B. OBJECTIVES 

The seven objectives developed to answer the research questions were: 

1. Document chat use cases across the services, including COCOMs, coalition 
partners, and OGAs. Use the joint warlighting functions and joint / combined doctrine as 
the framework guiding collection, analysis, and presentation of the use cases. 

2. Document the reasons for warfighter chat use across the same agencies listed 
in objective one. Collect, analyze, reduce, and report the attributes used by warfighters to 
communicate why they used chat. 

3. Introduce the more difficult to quantify risks associated with the integrity, 
confidentiality, and availability of chat and the effects of chat use on tactical information 
exchange and situational awareness. 

4. Consolidate the services’ explicitly stated chat requirements contained in 

numerous reports, briefings, emails, capabilities documents, etc. 
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5. Consolidate selected COCOM explicit chat requirements contained in 
numerous reports, briefings, emails, capabilities documents, etc. 

6. Develop a framework for chat requirements development that decomposes the 
chat problem to a level that users, engineers, and managers alike can use and understand. 

7. Define avenues for future research that support the further development and 
decomposition of combined and joint, text-based chat requirements for the next- 
generation C2 systems. 

C. SCOPE AND LIMITATIONS 

This thesis was limited to the following major tasks: consolidate the available, 
disparate information; develop the joint chat requirements; and evaluate the TRIDENT 
WARRIOR (TW05) results. The literature review was limited to documenting the 
concepts driving military C2 towards real-time collaboration. Requirements development 
was limited to problem definition and development of a high-level requirements 
framework for future chat / C2 tool development. This thesis limited the technical review 
of chat protocols, chat tools, and chat architectures to what supported the research 
questions and the experimentation. 

D. THESIS ORGANIZATION 

Chapter II surveys the joint and service concepts driving the evolution of C2, 
doctrine, and defense acquisition. Chapter III provides the methodology for data 
collection, analysis, and experimentation. The chat use cases, reasons for chat use, chat 
risks, and chat requirements are reported in Chapter IV. Chapter V presents opportunities 
for future research and concludes. 
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II. LITERATURE REVIEW 


No single body of work defines text-based chat usage for military C2, making a 
significant, top down literature review necessary. The evolutions in joint force doctrine 
and current operations drive the changes in military C2 that create capability gaps leading 
to the surge in chat use. This review starts with the doctrine driving the development of 
the future joint force and subsequent transformation of the services. Continuing to drill 
down, we look at the service visions, their transformation roadmaps, and their technology 
enablers for providing the necessary C2 capabilities to operate as part of the future joint 
force. Finally, we study the small body of unclassified research focused on military chat 
use. This work is grouped in three categories: technical, human systems integration 
(HSI) and a key piece on the risks associated with chat. 

A. FUTURE JOINT WARFARE 

The DOD’s Capabilities-Based Assessment (CBA) process bridges strategic 
guidance and future joint force capabilities, and the Joint Operations Concepts (JOpsC) 
family of concepts is the result. The goal is to design, from the ground up, a future joint 
force that is fully integrated, expeditionary, networked, decentralized, adaptable, lethal, 
and possesses decision superiority (JCS J7 2006). 

The JOpsC is a hierarchy of living documents based upon both future vision and 
lessons learned from current operations. They are the doctrinal framework for future full- 
range military operations (JCS J7 2006). Services and other defense agencies develop the 
Doctrine, Organization, Training, Material, Leadership and Education, Personnel and 
Facilities (DOTMLPF) solutions to achieve the capabilities enumerated in the JOpsC. 
Service and joint experimentation evaluate these capabilities and their ability to support 
decisive operations across the full military spectrum. Figure 2 depicts the JOpsC 
hierarchy. 
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(JOpsC) 

Joint Operations Concepts 



Figure 2. Joint Operations Coneepts (JOpsC) Hierarehy (From; CJCS 2004) 


The JOpsC play a eentral role in the Joint Capabilities Integration & Development 
System (JCIDS) and support the Chairman of the Joint Chiefs of Staff (CJCS) and the 
JROC in assessing and prioritizing joint military eapability needs (CJCS 2005). The 
JOpsC guide the funetional eapability analyses that are eaptured in the eapability 
doeuments required for Milestone Deeisions in defense aequisition projeets. This proeess 
is eaptured in Figure 3 (“Family of Joint Future Coneepts” refers to the JOpsC). 
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1. The Capstone Concept for Joint Operations 

The Capstone Coneept for Joint Operations (CCJO) (2005) is the DOD’s capstone 
concept for future joint warfare. The CCJO provides the broad outline of how the future 
joint force will operate and the subordinate Joint Operational Concepts (JOCs) and the 
services’ concepts expand upon the CCJO guidance. The CCJO (2005) calls for joint 
forces to interoperate and share, collaborate, coordinate maneuver, and integrate 
situational awareness. These concepts seek to create a knowledge-empowered force that 
makes better, faster decisions at all levels and increases joint force effectiveness (CCJO 
2005). 

The concepts the CCJO sets forth require significant evolution in joint C2. Of 
particular note, the CCJO (2005) defines lethality as “the ability to leverage technology to 
destroy the adversary and/or his systems at range or in close combat.” This sets the stage 
for interim capability gaps in current C2 systems that are being plugged with text chat. 

2. Joint Operating Concepts 

The four JOCs address the environments, the challenges, and the evolution in 
DOTMLPF required for the future joint force to operate across the full spectrum of 
military operations. The JOCs are summarized in Table 1. 


Table 1. 

Joint Operating Concept 

Joint Operating Concepts Summary 

Summary 

Major Combat Operations 

Establishes the framework for transitioning the armed forees from the 
industrial age to the teehnology age with emphasis on eondueting large- 
seale military aetions in a distributed, eollaborative environment. 

Homeland Defense and Civil 
Support 

How DOD intends to perform its responsibilities assoeiated with 
seeuring the Homeland, to inelude Homeland Defense (HLD), Civil 
Support (CS), and Emergeney Preparedness (EP) in the 2015 timeframe. 

Strategic Deterrence 

How Joint Foree Commanders will plan, prepare, deploy, employ, and 
sustain a joint foree to eontribute to a strategie deterrenee strategy set 
forth by national leadership through 2015. 

Stability Operations: Military 
Support to Security, 
Transition & 
Reconstruction 

"The joint foree, as part of a multinational and integrated, multi-ageney 
operation, will provide security, initial humanitarian assistance, limited 
governance, restoration of essential public services, and other 
reconstruction assistance.” 


Sources: (Major Combat Operations Joint Operating Coneept 2004; Homeland Defense and 
Civil Support Joint Operating Coneept 2005; Strategie Deterrenee Joint Operating Coneept 2004; 
Stability Operations: Military Support to Seeurity, Transition, and Reeonstruetion Joint Operating 

Coneept 2004) 
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Each JOC lists robust future C2 requirements; however, these requirements are 
needed by today’s eommanders. A brief examination of these requirements helps explain 
the origin of capability gaps in today’s military C2 systems. 

The Major Combat Operations Joint Operating Concept (MCO JOC) (2004) 
declares the rapid advance and proliferation of “information age” teehnologies require 
fundamental changes in how we approaeh warfare and conflict resolution. For achieving 
this eentral theme the MCO JOC (2004) states: 

Deeisive conclusions are enabled by the fluid and coherent application of 
joint military action in conjunction with interagency and coalition power, 
using an effects-based approach and leveraging pervasive knowledge in a 
networked environment to inerease levels of eollaboration, preeision, unity 
of purpose and coherency in action. 

The Homeland Defense and Civil Support Operating Concept (HLD CS JOC) has 
eight enabling capabilities. Four of these capabilities listed in the HFD CS JOC (2005) 
are supported by chat: 

• Ensure a eollaborative and interoperable DOD and interagency partner 
unity of effort against threats to the Homeland, to include eonsequence 
management operations 

• Develop and maintain situational awareness and shared understanding 
throughout the HFD/CS/EP environments 

• Develop and maintain a robust, redundant, secure, deeentralized, 
distributed, eollaborative, and interoperable command, control, 
communications, computers, and intelligence (C4I) system and proeess 

• Develop and maintain robust interagency coordination to include 
communieations interoperability, intelligence sharing, and 
policies/proeedures on entrance and exit strategies for DOD involvement 

The Strategic Deterrence Joint Operating Coneept (SD JOC) (2004) defines two 
key eapabilities: global situational awareness and robust global C2. Global situational 
awareness involves gathering intelligence required for deterrence operations. This 
requires persistent intelligence, surveillance, and reconnaissance (ISR) efforts in a 
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collaborative environment. Global C2 calls for a horizontally and vertically integrated 
distributed network to provide key leadership with an effective and survivable command 
and control capability (SD JOC 2004). This C2 capability must gracefully degrade to a 
small, but absolutely reliable channel. 

The Stability Operations: Military Support to Security, Transition & 
Reconstruction Joint Operating Concept (SO JOC) is particularly relevant to OEF and 
OIF. This JOC lists numerous C2 and battlespace awareness capabilities required for 
suecess. Table 2 summarizes those capabilities required in OFF and OIF that drive ehat 
use. 


Table 2. SO JOC Capabilities Driving Chat Use in OEF and OIF 

Command and Control Battlespace Awareness 


— The ability to conduct collaborative, 
planning, execution, and information sharing 
among US civil-military agencies and 
coalition partners from the operational to 
tactical levels. 

— The ability to achieve multi-agency 
coherency of action during planning, 
coordination, and execution by creating a 
joint, and combined when necessary, multi¬ 
agency planning and execution organization 
empowered to facilitate integrated civil- 
military operations. 

— The ability to enhance rapid information 
sharing with coalition members, multi¬ 
agency players, and non-govemmental 
organizations through information sharing 
technologies and policies. 

— The ability to field a command and control 
system with reach back capability and 
connectivity to facilitate other agency 
participation. 


— The ability to achieve a persistent 
situational awareness and shared 
understanding in a joint, multi-agency, and 
multinational context in order to know the 
operational environment and the 
interrelationship among ourselves, our 
adversaries, and the local population. 

— The ability to use an operational net 
assessment to support stability operations 
and to reflect that information in the 
integrated civil-military common relevant 
operating picture. 

The ability to provide persistent 
intelligence, surveillance and reconnaissance 
that integrates all intelligence capabilities, 
including human intelligence assets, into the 
overall intelligence, surveillance, and 
reconnaissance architecture. 


Source: (Stability Operations: Military Support to Security, Transition, and 
Reconstruction Joint Operating Concept 2004) 


These JOCs list numerous C2 and battlespaee awareness eapabilities required for 
the future joint forces to conduct operations across the full military spectrum. They rely 
heavily upon joint force connectivity throughout the battlespace to facilitate vertical and 
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horizontal collaboration during all operational phases aeross the speetrum of military 
operations. The current Global War on Terrorism (GWOT) is the type of eomplex 
eonfliet envisioned for the future joint foree. With the eurrent joint force already fighting 
the “future” conflict, we can see gaps empirieally in current C2 systems that have our 
warfighters looking for ad hoc solutions like text ehat. 

3. Joint Functional Concepts 

The Joint Functional Concepts (JFC) broadly addresses their respective functional 
areas across the range of military operations. The three impaeting C2 are: Net-Centric 
Environment (NC JFC), Command and Control (C2 JFC), and Battlespace Awareness 
(BA JFC). These three have direct impact on contemporary C2 issues and are driving 
future C2 development. The NC JFC, C2 JFC, and BA JFC are summarized in Table 3. 


Table 3. Select Joint Functional Capability Summary 


Joint Functional Summary 

Concept 

Net-Centric 

Environment 

“The Net-Centric Environment is a framework for full human and technical 
connectivity and interoperability that allows all DOD users and mission partners 
to share the information they need, when they need it, in a form they can 
understand and act on with confidence, and protects information from those who 
should not have it. ” 

Command and 
Control 

“In 2015 Joint C2 will be a joint decision-making process that is dynamic, 
decentralized, distributed, deployable, and highly adaptive. Enabled by a robust, 
secure, integrated network, and through the employment of collaborative 
information environments, the Joint Force Commander will possess a seamless, 
deployable command and control capability. ” 

Battlespace 

Awareness 

“Battlespace Awareness in 2015 provides actionable intelligence to commanders 
and warfighters. This capability, enabled by a thorough understanding of the 
battlespace focusing on the adversary and other relevant factors, brings to bear a 
responsive system-of-systems fully integrating personnel, documents, equipment, 
and technical means in providing persistent, redundant, and tailored coverage. ” 


Sources: (Net-Centric Environment Joint Functional Concept 2005; Joint Command and 
Control Functional Concept 2004; Functional Concept for Battlespace Awareness 2003) 


4. Joint Integrating Concepts 

The Joint Integrating Concepts (JICs) address speeific military problems within 
the broad functional areas of the JFCs. The two impacting C2 are: Command and 
Control (C2 JIC) and Net-Centric Operating Environment (NC JIC). These JICs address 
the required tasks and standards within the funetional areas. This lends them to 
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identification, assessment, and analysis of capability gaps and solutions. The C2 JIC and 
NC JIC are summarized in Table 4. 


Table 4. Select Joint Integrating Concept Summary 


Joint Integrating 
Concept 

Summary 

Command and 
Control 

“This Joint Integrating Concept (JIC) promotes the development of C2 capabilities 
for agile, decisive, and integrated force employment in all phases of combat and 
supporting operations, as required by the National Military Strategy. ” 

Net-Centric 

Environment 

“The concept’s central idea is that, for the future Joint Force to achieve decisive 
levels of shared knowledge and technical connectivity, the NCOE must provide the 
Joint Force with pervasive knowledge through the full integration of knowledge 
management KM), network management (NM), and information assurance (lA). ” 


Sources: (Command and Control Joint Integrating Concept 2005; Net-Centric Operational 
Environment Joint Integrating Concept 2005) 


B. SERVICE VISIONS AND TRANSFORMATION 

The service visions, transformation plans, and technology enablers focus, like the 
JOpsC, on leveraging technology to destroy the adversary. They are listed by service in 
Table 5 and then discussed by service in the following sections. 


Table 5. Vision, Transformation, and Technology Doctrine by Service 


Service 

Vision 

T r ansfor mation 

Technology 

US Army 

FM:1 The Army 

Army Transformation 
Roadmap 

LANDWARNET 

US Air Force 

America's Air Force 
Vision 2020 

U.S. Air Force 
Transformation Flight 
Plan 2004 

Command and Control 
(C2) Constellation 



Naval Transformation 
Roadmap 2003 

FORCEnet: A 

US Navy 

Sea Power 21 

Functional Concept for 
the 21st Century 

US Marine Corps 

Strategy 21 

Marine Capstone 
Concepts 

Marine Air Ground 
Task Force Command 
and Control 


I. United States Army 

a. Field Manual 1: The Army 

Field Manual (FM) 1; The Army (2005) establishes the principles for land 
power employment that drive Army doctrine and looks at Army contributions to the 
future joint force. This vision also sets forth Mission Command as the Army’s preferred 
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C2 method. Mission Command implementation is supported by two eomponents of the 
Army Vision: integrating eomponent technology of future combat systems and 
developing networked information systems. The integration component includes sensors, 
information systems, and manned and unmanned vehicles to improve commanders’ 
situational awareness (SA). The networked component is a family of networked land and 
airborne maneuver and supporting systems built around the soldier. 

b. Army Transformation Roadmap 

The 2004 Army Transformation Roadmap (2004) explains how the Army 
will maintain current capabilities while developing new capabilities required for the 
future joint force. The Army intends its Future Combat Systems (FCS) to achieve the 
integration of component technology of future combat systems and development of 
networked information systems called for in FMl. Finally, the Army’s roadmap sets 
forth LandWarNet for tying together its FCS equipped forces and integrating them into 
the Global Information Grid (GIG). 

c. LANDWARNET 

The Army LandWarNet literature consists primarily of a collection of 
presentations, reports, and briefs. The Army Chief Information Officer (CIO)/G-6 and 
the Army Training and Doctrine Command (TRADOC) are developing the 
LANDWARNET concept with Network Enterprise Technology Command 
(NETCOM)/9th Army Signal Command (Public Affairs Guidance (PAG) on Army Eocus 
Area, The Network 2005). EandWarNet is the Army Enterprise Network, its portion of 
the GIG, providing networks to the Active Component forces. National Guard, Army 
Reserve, and sustaining bases (LANDWARNET: Network Strategy for Eand Combat 
2004). Three interrelated, integrated, and interactive domains comprise 
EANDWARNET: communications, computing infrastructure, and core enterprise 
services (Public Affairs Guidance (PAG) on Army Eocus Area, The Network 2005). 

2. United States Air Force 

a. Americans Air Force Vision 2020 

America’s Air Eorce Vision 2020 (2000) envisions a future aerospace 
force whose contributions to the future joint force are based on its technological and 
operational developments that increase its combat capability. The C2 challenges of this 
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future aerospace force stem from the required global integration of distributed space, 
airborne, and land components with information operations (10). 

b. U.S. Air Force Transformation Flight Plan 2004 (Flight Plan) 

Flight Plan (2004) is how the Air Force is transforming and developing its 

military capabilities, with emphasis on joint and coalition warfighting enablers, as part of 
the future joint force. Appendix D details Flight Plan support to the required JOpsC 
capabilities. Flight Plan focuses on a methodology for Air Force transformation rather 
than specifics. There is emphasis on the role of science and technology development to 
address six long term challenges including global integration of air and space C2. 

c. Command and Control (C2) Constellation 

The Concept of Operations (CONOPS) for Command and Control (C2) 
Constellation version 8 (2003) draws on the objectives and desired effects of the Space 
and C4ISR CONOPS established in the Flight Plan to quickly deliver information to the 
warfighter. The CONOPS for C2 Constellation (2003) will provide: 

“...standard network services and a shared Combat Information 
Environment to C2 centers and Joint and coalition combat and combat 
support aircraft to enable the flow of decision-quality information and 
support warfighter collaboration by creating an intuitive decision 
environment through full access to battlespace information. Current 
discrete air, ground, and space networks will be adapted and 
interconnected to form a seamless information dissemination grid.” 

Battlefield Management Command and Control (BMC2) is the heart of the 
C2 Constellation that will eliminate the current stovepipe systems and integrate the 
required elements to achieve the desired Air Force capabilities outlined in America’s Air 
Force Vision 2020. 

3. United States Navy 

a. Naval Power 21 

Naval Power 21 (2002), signed by both the Chief of Naval Operations 
(CNO) and the Commandant of the Marine Corps (CMC), presents a vision based on 
three pillars: we assure access, we fight and win, and we are continually transforming to 
improve. This document provides the foundation for the Navy’s Sea Power 21 and 
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Marine Corps’ Strategy 21 visions and eoneepts for aehieving their required serviee 
eapabilities and their required eapabilities as part of the future joint foree. 

b. Sea Power 21 

Sea Power 21 (2002) defines the three interdependent Navy Capability 
Pillars (NCP): Sea Basing, Sea Strike, Sea Shield, and their network-eentrie enabler, 
FORCEnet. These eoneepts ereate the eurrent and future eapabilities that will ensure the 
Navy’s ability to fulfill its portion of Naval Power 21. These eoneepts rely on 
information management (IM) and knowledge management (KM) to eompress and 
inerease the lethality of the C2 proeess. The required information superiority is provided 
by networked sensors, platforms, and systems, persistent ISR, and 10. 

c. Naval Transformation Roadmap 2003 

The Naval Transformation Roadmap 2003 (2003), signed by both the 
CNO and CMC, states that every aspeet of naval transformation is driven by joint 
prineiples to develop the NCPs required by the future joint foree. This doeument maps 
the naval eapability pillars against the JOpsC, illustrating their applieability. The 
roadmap explains how current and future Navy and Marine Corps capabilities must 
integrate to provide robust, joint C2 to land, airborne, sub-surface, surface, and space 
forces operating globally. 

d. FORCEnet: A Functional Concept for the 21st Century 

FORCEnet: A Functional Concept for the 21st Century (2005), signed by 

the CNO and CMC, defines FORCEnet as “the operational construct and architectural 
framework for naval warfare in the Information Age, integrating warriors, sensors, 
command and control, platforms, and weapons into a networked, distributed combat 
force.” FORCEnet provides the network-centric capabilities enabling the NCP concepts. 
FORCEnet allows the Navy-Marine Corps Team to generate the capabilities called for in 
Naval Power 21 and the JOpsC, and readies naval forces for their role in the future joint 
force. 

4. United States Marine Corps 

a. Strategy 21 

Strategy 21 (2000) provides the broad visions, goals, and aims to develop 
future USMC combat capabilities and contributions to Naval Power 21. Expeditionary 
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Maneuver Warfare (EMW) is the eenterpieee of the Marine Corps vision. Strategy 21 
(2000) states, “Marine Corps Strategy 21 guides a Marine Corps eapable of 
aceomplishing its specified and implied tasks derived from the guidance in the National 
Security Strategy, the National Military Strategy, and other strategic documents.” 
Originally developed to meet the Joint Vision 2020 (JV2020) guidance on the evolution 
of the armed forces. Strategy 21 speaks in terms of capabilities and remains relevant in 
creating Marine Corps capabilities to support the JOpsC as part of the future joint force 
(Capstone Concepts 2005). 

b. Marine Capstone Concepts 

U.S. Marine Corps Concepts and Programs 2005 (2005) sets forth EMW 
as the capstone concept guiding how the USMC will organize, deploy, employ, and 
sustain current and future forces. Incorporated into EMW are the concepts Operational 
Maneuver from the Sea (OMETS), Ship to Objective Maneuver (STOM), Sustained 
Operations Ashore (SOA), and Other Expeditionary Operations (OEO). Additional 
concepts are Distributed Operations (DO) and Information Operations. These concepts 
drive the need for a robust, integrated, and networked C2 capability. They require 
sustained, over the horizon operation by units of various sizes throughout the battlespace 
and may in fact shape the battlespace, as demonstrated by the GWOT. 

c. Marine Air Ground Task Force Command and Control 

The Marine Air Ground Task Eorce Command and Control (MAGTE C2) 
program exists primarily as a collection of briefs outlining the concept. The presentation 
MAGTE C2 Strategy (2005) describes MAGTE C2 as: “... end to end, fully integrated, 
cross functional set of MAGTE C2 capabilities that include forward deployed as well as 
reach back.” Essentially, MAGTE C2 envisions a system of systems to achieve 
integration and interoperability. Dukes (2005), in his MAGTE C2 Brief to the ISR 
Operational Advisory Group (OAG), states C2 must be joint and mapped the MAGTE C2 
layers to the EORCEnet capabilities. 

C. MILITARY CHAT RESEARCH 
I. Center for Naval Analyses 

The Center for Naval Analyses (CNA) researched chat performance in the fleet 
during OEE, OIE, and various experiments. This research was conducted for the Office 
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of the Chief of Naval Operations (OPNAV) N61 and Commander of Naval Network 
Warfare Command (NETWARCOM). The findings are reported in the following four 
doeuments. While the researcher reviewed classified CNA reports, only unclassified 
CNA work is discussed here. 

a. Proposed NETWARCOM Guidance: The Effective Use of Chat 
Banerjee and Bentrup (2002) document how the introduction of chat 

outpaced the fleet’s understanding of how best to use and manage it. The authors 
develop an analytical framework for a Navy IM plan to aid NETWARCOM in providing 
clear guidance to the fleet regarding chat use (Banerjee and Bentrup 2002). 

b. Fleet Chat Requirements 

In this white paper Banerjee and Bentrup (2003) wrote that an at-sea 
environment places unique requirements on collaborative tools, outlined the fleet chat 
requirements, and compared a number of different tools against those requirements. 
They reported that while DCTS met the requirements of shore-based users, it fell short of 
meeting the at-sea requirements they outlined. 

d. Distributed Internet Relay Chat Architecture 

Bentrup, Banerjee, and Baldwin (2005) discuss distributed IRC 
architectures, one of the recommendations from in the CNA report Elect Chat 
Requirements. The distributed IRC architecture was compared to the Navy’s traditional 
hub-and-spoke architecture. The findings are summarized in Table 6. 


Table 6. Summary of Eindings Erom Distributed Relay Chat Architecture (After: Bentrup, 
_ Banerjee, and Baldwin 2005) _ 

1. A distributed chat architecture is superior to the current hub-and-spoke architecture 

2. Greater savings can be achieved by compressing the server-to-server links 

3. A distributed chat architecture is compatible with the current hub-and-spoke architecture. 

4. The fleet needs to use a single version of IRC server software. 

5. The fleet needs to recognize the value of open source products. 


c. Trident Warrior 04: Distributed Internet Relay Chat Architecture 
for Afloat Networks 

Bentrup, Banerjee, and Baldwin (2005a) analyze the distributed IRC 
architecture used during the Navy’s TW04. Areas studied included: chat reliability. 
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server-to-server connectivity and reconnect, bandwidth efficiency and costs, chat 
availability, and affect on SA. Table 7 summarizes the operational results from the 
experiment. 


Table 7. TRIDENT WARRIOR 04 Distributed Chat Architecture Operational Results 
_ Summary _ 

1. Shipboard server allowed users aboard USS TARAWA to chat intra-ship during 
communications outages 

2. Situational Awareness improved: chat history, reduced down time, faster reconnects, and 
improved situational awareness on reconnect 

3. Chat uptime (availability) improved by 27% and average duration connection improved by a 
factor of 5 


2. Pacific Science & Engineering Group 

The Pacific Science & Engineering Group (PACSCI) research focuses on the HSI 
aspects of Navy chat use and its evolution. 

a. Survey of Chat Usage in the Fleet: Results 
Moore and Heacox (2005) documented the evolution of chat use during 
OEE and OIE. Surveys from 183 OIE chat users captured chat usage patterns and some 
perceived warfighter requirements. The survey was hosted online using one of 
Commander, Carrier Group One’s (CCG-1) servers. The survey results are reported by 
the categories taken from the sample demographics. 

Moore and Heacox (2005) discovered that 79 percent of respondents 
participated in one to four chat rooms and that 23 percent participated in 5 or more. 
While participating in these chat rooms, 65 percent of respondents monitored one to four 
additional chat rooms and 23 percent monitored an additional five or more (Moore and 
Heacox 2005). Eigure 4 shows what four of the respondent groups used chat for. 
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Figure 4. Purpose for ehat use (as pereentage) by respondent group (After: Fleacox and 

Moore 2005) 


b. Usability of Chat in the Maritime Coalition Environment: 
Empirical Findings from a Limited Objective Experiment for 
Trident Warrior 2005 

Catanzaro, Gwynne, and Mitehell (2005) report their findings from a LOE 
where novice and experienced chat users performed a series of 24 tasks. Task 
performance was evaluated for five different chat tools, summarized within this report, 
with an individual report for each chat tool (listed in the bibliography). Catanzaro, 
Gwynne, and Mitchell (2005) concluded that chat HSI features should be implemented in 
terms of the operational requirements for chat in a maritime coalition environment, that 
there are numerous interface design features that affect the chat tools’ ability to meet 
these requirements, and that a prioritized list of chat features can be used to develop 
interface design guidelines for naval chat. 

3. Massachusetts Institute of Technology 

In Cummings (2004), Need for Command and Control Instant Message Adaptive 
Interfaces: Lessons Learned from Tactical Tomahawk Human-in-the-Loop Simulations, 
researchers uncovered some interesting data concerning chat use. Results indicated that 
some operators focused on the chat tool rather than their primary task of missile control, 
which lead to degradation of performance and SA. 
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This is some of the first researeh doeumenting some of the issues arising from the 
proliferation of ehat use. The results of the report are not unexpeeted and are in faet often 
discussed within the military, but only generally and anecdotally. 
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III. METHODOLOGY 


A. RESEARCH 

The very nature of ehat’s unofficial status made the study of existing research 
difficult. Most chat-related documents consist of briefs and presentations, unpublished 
internal reports, and email discussions. Significant and continued effort was spent 
soliciting, collecting, and consolidating these materials into the required knowledge base. 
Once accomplished, information gaps were identified with three key gaps becoming 
immediately apparent: 

• most information addressed chat indirectly and at the service level or 
major command level 

• information collected from “lower levels” provided no documentation of 
what “lower levels” actually referred to, nor was the summarized or raw 
input available 

• no one was in charge of chat, at best a person involved in collaboration 
had some involvement, more commonly it was a civilian employee that 
“unofficially” addressed chat 

Based upon these key information gaps, this thesis focused its research effort at 
the tactical level. Example units are: Army Brigade (Brigade Combat Teams) and below. 
Marine Regiment (Regimental Combat Teams) and below. Air Force Squadron and 
below. Navy Expeditionary or Carrier Strike Groups down to the single ship. While 
focused on the tactical, research was also conducted to verify stated chat use and 
requirements at the operational and the strategic levels. 

1. DIRECT OBSERVATION 

The researcher’s personal experience as a US Marine Corps Command and 
Control Systems Officer (Military Occupational Specialty 0602) provided an applied chat 
knowledge base. This knowledge base includes the planning, installation, operation, and 
maintenance of various chat tools with infantry, artillery, special operations forces, and 
embarked amphibious units. Experience gained using chat as a watch officer 
demonstrated the difficulties in successfully integrating chat with warfighting doctrine. 
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The researcher also participated in the Navy’s annual Sea Trial Experiment, 
TW05. This allowed the researcher to observe and participate in planning, chat tool 
development, chat limited objective experiments, and document first hand joint and 
coalition chat use at sea during a major joint and combined exercise scenario with a US 
Navy Expeditionary Strike Group. 

2. SURVEYS AND INTERVIEWS 
a. Selecting Participants 

The survey and interview process targeted military officers at the tactical 
level, pay grades 0-3 and 0-4. This group represents typical unit commanders, staff 
officers, and watch officers across the services. Appendix B provides the full survey 
demographics of respondents. Table 8 summarizes the pay grades of respondents by 
service from Appendix B. 


Table 8. Pay grades of respondents by service 


Organization 

05 

04 

03 

02 

Total 

US Marine Corps 

0 

10 

16 

2 

28 

US Air Force 

0 

6 

8 

1 

15 

US Navy 

1 

2 

4 

0 

7 

US Army 

0 

2 

1 

0 

3 

Canadian Forces 

0 

0 

1 

0 

1 

Royal New 
Zealand Navy 

0 

1 

1 

0 

2 

Royal Australian 

0 

1 

0 

0 

1 

Navy 

Total 

1 

22 

31 

3 

58 
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Table 9 summarizes the operational tours of respondents by operation 
From Appendix B. 


Table 9. Number of tours of survey respondents by operatio n 


Operation 

Tours 

ENDURING FREEDOM 

23 

ENDURING FREEDOM-PHILIPPINES 

I 

IRAQI FREEDOM -1 

26 

IRAQI FREEDOM - II 

9 

SUBSEQUENT IRAQI FREEDOM ROTATION 

2 

SOUTHERN WATCH 

7 

UPHOLD DEMOCRACY 

I 

ALLIED FORCE 

I 

PROVIDE COMFORT 

I 

SECURE TOMRROW 

I 

JTF-Katrina 

2 

ALTAIR (CANADIAN OEF PARALLEL) 

I 

UNISON (CANADIAN KATRINA RELIEF) 

I 


b. Administering Surveys and Interviews 

The surveys and interviews were administered with the same deviee from 
Appendix C to ensure continuity of results between the two forms of data collection. 
Rather than use a web-based survey, the survey was emailed to participants to introduce a 
response bias, limiting respondents to those that had actually used chat and were willing 
to take the time to complete the survey, save it, and email it back. This resulted in 
extremely high quality responses that were easily incorporated into the research. Despite 
this built-in bias, there were still numerous responses that were simply not useful or the 
respondent never used chat. 

3. AAR/LL 

UNCLASSIFIED, CONFIDENTIAL, and SECRET after action reports and 
lessons learned were reviewed. In an effort to reach the broadest possible domestic and 
foreign audience, only the UNCEASSIEIED are reported on specifically in this thesis. 
An in-depth review of the classified reports and lessons learned found no substantive 
differences from the UNCEASSIEIED ones; they simply contained non-releasable 
specifics and details. Table 10 provides the number of action reports and lessons learned 
reviewed by organization. 
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Table 10. Number of After Action Reports/Lessons Learned by organization 

Organization _ Number _ 


US Army 

18 

US Navy 

570 

US Air Force 

70 

US Marine Corps 

107 

US Coast Guard 

220 

Combatant 

Command 

17 


B. DISCUSSION 

Much of this thesis research was qualitative. Surveys, supplemented with 
extensive personal communication were used to uncover user expectations and common 
requirements in collaboration tools. 

C. ANALYSIS 

The unstructured nature of the text-based chat requirements and lack of clear 
problem definition required an artful, systems architecting approach. The two 
architecting methodologies primarily used were the Participative (stakeholder-based) and 
the Heuristic (lessons learned) and are considered the “art” part of systems engineering 
(Maier and Rechtin 2002). The ad hoc nature that led us to this point in chat use dictates 
that a participative, stakeholder approach is critical. The fact that the chat “problem” 
(however undefined) is only now being addressed, after years of actual operational use, 
means there exists some historical record of use that we may apply heuristics to draw 
insight. However, scientific methodologies like the normative (solution-based) or the 
rational (methods-based) were also used. 

The participative methodology recognizes numerous, conflicted stakeholders exist 
and makes its objective consensus (Maier and Rechtin 2002). This plays to chat’s wide 
use, its varied users, and the proliferation of tools. The heuristic methodology is a 
“common sense” approach based on collective wisdom simply and concisely stated 
(Maier and Rechtin 2002). 

Systems engineers/architects and project managers may only work on a few major 
projects in their lifetime, resulting in a focused experience within a certain field. 
Heuristics serve as an abstraction for experience, allowing people to draw on past 
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experience from other fields and functions to address problems within their own (Maier 
and Rechtin 2002). 

This thesis focused on warfighter involvement and chat lessons learned to clearly 
state the problem, document experience, and develop a framework that allows future 
researchers to scientifically approach text-based chat. In parallel, this thesis also 
participated in major scientific experimentation regarding text-based chat to aid in the 
research and to act as a check and balance. 

D. EXPERIMENTATION 

I. TRIDENT WARRIOR Objectives 

“Define Navy FORCEnet DOTMLPF requirements for a maritime chat tool” was 
a stated objective of TW05, NETWARCOM’s annual EORCEnet Sea Trial exercise 
(TW05 Analysis Report 2006). Table 11 lists the IM chat initiative objectives. 


Table 11. 1 

[RIDENT WARRIOR Information Management chat-related objectives 

Objective 2 

Universal Chat Client (UCC) - Assess the eapability of UCC to fill the doeumented gaps that 
eurrently exist in eurrent maritime ehat protoeols used throughout the US Navy. 

Objective 3 

Uber Chat - Does Uber Chat provide funetionality that fills identified gaps in eurrent maritime 
ehat protoeols? 

Objective 4 

Extensible Messaging and Presence Protocol (XMPP) - Does XMPP provide funetionality 
that fills identified gaps in eurrent maritime ehat tools? 

Objective 5 

Multi-Level Chat (ML Chat) - Does ML Chat’s unique funetionality of ehatting aeross two or 
more domains provide the funetionality neeessary for Navy Maritime Chat? 

Objective 6 

Persistent War Room (PWR) - Will PWR and Chat Logging operate over lower bandwidth 
subnets and provide the operator ready aeeess to ehat funetions and supporting information as 
well as arehived ehat logs? 

Objective 8 

Distributed Chat Architecture (DCA) - Compare the proposed DCA (hub and leaf) to the 
eurrent (hub & spoke) IRC eommunieations arehiteeture. Provide a teehnieal solution to 
operator eoneems ineluding loss of situational awareness, reeonneetion to servers after a 
eommunieations outage, intra-ship text ehat eommunieations when off-ship eommunieations are 
down. 


Source'. TW05 Analysis Report 


The experiment was conducted at sea while executing a week-long tactical 
scenario that included US naval and coalition ships, embarked 24th Marine Expeditionary 
Unit Special Operations Capable (MEU (SOC)) staff, shore-based units, and numerous 
manned and unmanned aircraft. Different data network conditions were implemented to 
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evaluate the objeetives under communieations conditions from ideal to severely 
degraded. 

The thesis researcher worked with NETWARCOM’s TW05 IM Lead during all 
stages from planning through execution. This provided the opportunity to participate 
with one of the services on defining their chat requirements as part of a major joint and 
coalition experiment with the USS IWO JIMA ESG, the 24th MEEi (SOC), and the 
AUSCANNZUKUS coalition. 

In preparation for TW05, the researcher participated in a risk reduction LOE 
conducted at SSC-SD. The LOE had two parts. In first part researchers from the CNA 
tested the distributed chat architectures planned for use during TW05 and simulated the 
various network conditions planned. 

The second part consisted of HSI studies conducted by PACSCI on the chat tools 
that were going to be used during TW05. This was crucial to the spiral development 
approach used for some of the chat tools. They were developed with previously collected 
and developed chat tool requirements. The LOE allowed the PACSCI scientists to 
observe users operating the chat tools and develop a refined requirements list. These 
refined requirements allowed the NETWARCOM IM Lead and the chat tool developers 
to re-design the chat tools in preparation for TW05. 

2. TRIDENT WARRIOR Background 

TRIDENT WARRIOR operates under the supporting concept of Sea Trial that 
supports the Naval Capability Pillars. Sea Trial: Commander U.S. Fleet Forces 
Command Instruction (COMFLTFORCOMINST) 3900.1 (2003) establishes 

responsibilities and prescribes general procedures for Sea Trial implementation and states 
the Marine Corps, as part of the naval force, is an equal partner at all levels of Sea Trial, 
with the Commanding General (CG), Marine Corps Combat Development Commanded 
(MCCDC) the Marine Corps Sea Trial coordinator. 

The Sea Trial Executive Steering Group (STESG) members defined by Sea Trial 
include major Navy and Marine Corps commands and agencies. The instruction 
designates Commander Naval Network Warfare Command (COMNAVNETWARCOM) 
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as the Sea Trial Operational Agent for FORCEnet. Naval Postgraduate Sehool is tasked 
with concept development and research in support of the NCPs and FORCEnet. 
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IV. FINDINGS 


This chapter has four sections: chat use eases, an analysis of why ehat is used, an 
examination of chat’s risks, and a requirements framework. 

A. USE CASES 

The warfighter has expanded the role of ehat aeross the full speetrum of military 
operations. Commanders and innovative operators at all levels and units have grown 
their own ehat solutions to eomplex C2 problems despite the many systems fielded to 
solve the same. Chat is used by the warfighter to put steel on target, or eonversely, to 
build sehools and repair mosques. These operational examples are intentionally broad to 
provide a brief yet substantive illustration of the far-reaching use of ehat for military C2. 
Table 12 lists these use eases by functional area. 


Table 12. Use eases by functional area 


J-3 Operations 

J-2 Intelligence 

Multinational Operations 

Counterintelligenee 

Disaster Relief Operations/Civil 
Military Operations 

National Intelligenee Support to Joint 
Operations 

Antiterrorism/Homeland Defense 


Speeial Operations 

UAV Operations 

Targeting 

Close Air Support 

Combat Reeovery 

Medieal Evaeuation 


Meteorologieal and Oeeanographie 
Support to Joint Operations 



1. J-3 Operations 

a. Multinational Operations 

Her Majesty’s Canadian Ship (HMCS) TORONTO (FFH-333) 
partieipated in OPERATION ALTAIR (Canadian OEF parallel) in 2004. She deployed 
as a fully integrated eseort of the USS GEORGE WASHINGTON’S (CVN-73) Carrier 
Strike Group (CSG) to the Arabian Gulf. 
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The CSG exercised C2 with chat over SIPRNET (Secure Internet Protocol 
Routed Network), which HMCS TORONTO (the CSG’s only foreign ship) could not 
access. Canadian Forces task by voice; however, the CSG used the coalition wide area 
network (COWAN) chat for tasking HMCS TORONTO, with voice circuits as backup. 
United Kingdom and New Zealand vessels in the area of operations (AO) were also on 
COWAN chat. 

TORONTO stood picket duty in sector screen for the CSG, tasked and 
coordinated over COWAN chat. Tasking orders for urgent maritime interdiction 
operations (MIO) were sent to HMCS TORONTO over the COWAN chat and she 
boarded 123 ships for the CSG. 

The Combat Officer, HMCS TORONTO summed up chat issues from the 
Canadian point of view. The U.S. Navy did not rely on a single chat tool for C2. With 
HMCS TORONTO as the only non-U.S. warship it was easy for the CSG to overlook the 
need to use COWAN chat. Even with a liaison officer (ENO) aboard the George 
Washington and six months together, the U.S. never made the leap to using COWAN and 
continued using primarily SIPRNET chat. The recommendation was that coalition forces 
should use coalition networks. 

b. Disaster Relief Operations/Civil Military Operations 

Amphibious Squadron Four (PHIBRON4), embarked aboard the USS 
IWO JIMA (EHD-7), used chat for C2 during humanitarian operations with Joint Task 
Force-Katrina (JTF-Katrina). Chat was used extensively to plan, task, and coordinate 
pre-deployment and underway. Upon arrival in New Orleans, the movement of 
amphibious craft for transporting personnel, equipment, and supplies ashore was 
coordinated and tracked through chat. Situation Reports (SITREPs) from the ships and 
detachments ashore were sent to PHIBRON4 with chat and then sent from PHIBRON4 to 
Amphibious Group 2 (PHIBGRU2) by the same means. After Hurricane Rita, the USS 
TORTUGA (LSD-46), in Cameron, Louisiana, passed information on its amphibious 
craft operations and SITREPs over chat to PHIBRON4, still embarked on the USS IWO 
JIMA in New Orleans. 
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Canada executed Operation UNISON in response to Hurricane Katrina, 
sending its East Coast Task Group, including HMCS TORONTO (FFH-333), to Biloxi, 
Mississippi during September and October of 2005. Operations were reported to the USS 
Saipan using Maritime Command Operational Information Network (MCOIN) chat 
(MCOIN facilitates Canadian maritime C2 with U.S. Navy). The Canadian Task Group 
requested and coordinated landing support for its engineers, wood, generators, and other 
supplies over MCOIN chat. 

United States Marine Forces Atlantic (USMARFORFANT) recognized a 
gap in its C2 capability during JTF-Katrina operations. The USMARFORFANT lessons 
learned from JTF-Katrina included one entitled “Real Time Information Dissemination.” 
Watch Officers had difficulty disseminating timely information with email. Citing 
successful chat usage in OIF for the conduct of fire [fire support] and unmanned aerial 
vehicle (UAV) operations, it was recommended that USMARFORFANT establish chat 
rooms to support real time information dissemination (Gray 2005). 

The Area of Responsibility (AOR) for the U.S. Southern Command 
(USSOUTHCOM) is a huge geographic area where disaster relief efforts are not 
uncommon and civil military operations (CMOs) are the norm. Headquarters 
USSOUTHCOM uses the chat capabilities of DOTS to coordinate and support CMOs in 
its AOR. Chat was used to coordinate disaster relief efforts for the flooding in Guatemala 
caused by Hurricane Stan in 2005. 

c. Antiterrorism/Homeland Defense 

An antiterrorism vignette from Commander Coast Guard District 14 
message 162008Z MAY 03, After Action Report; Terrorism Threat on Board Cruise Ship 
Fegend of the Seas (FOS), 22-24 April 03: 

On 22 April 2003 Royal Caribbean Cruise lines cruise ship Fegend of the 
Sea (FOS) was en route from Ensenada, Mexico to Hilo, Hawaii for a 
scheduled port call with 1668 passengers and 701 crewmembers. A 
cleaner found a written note in a restroom threatening the lives of 
American passengers onboard. FOS reported the note to Royal Caribbean 
Cruise Fines who informed the National Response Center (NRC) and the 
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Federal Bureau of Investigation (FBI). Captain of the Port, Honolulu, 
ordered LOS to not enter port and divert to anehorage offshore. A 123 
member multi-agency boarding was conducted to secure and clear LOS 
(D14 2003). 

Coast Guard District 14 (D14) assumed Lead Federal Agency (LFA) for 
the boarding and operated in two SIPRNET chat rooms that included USCG Pacific Area, 
US Pacific Command (USPACOM), Commander U.S. Pacific Fleet, and 93rd Weapons 
of Mass Destruction Civil Support Team (93rd WMD-SCT). 

A Marine Corps Visit, Board, Search and Seizure (VBSS) vignette from 
the 2003-2004 deployment of the 13th MEU (SOC) in the Arabian Gulf: 

The Maritime Special Purpose Eorce (MSPE) Commander is aboard the 
shouldering ship with laptop and chat connectivity. The Eorce Platoon 
Commander is on the boarded vessel. They were in contact over voice 
radio, but the MSPE Commander was in contact with the handing Eorce 
Operations Center [LEOC] aboard a US Navy amphibious ship using chat. 
Prowords for mission segments, information requests, and the unfolding 
mission were passed and tracked in chat. The LEOC passed additional 
tasking to the MSPE as the mission progressed. The VBSS resulted in the 
seizure of hashish with an estimated value in the millions. 

d. Special Operations 

In 2002 and 2003, during OEE in Afghanistan, units from Third Special 
Eorces Group (Airborne) operated widely dispersed as part of the Combined Special 
Operations Task Eorce (CJSOTF). Third Group was equipped with AN/PSC-5 Satellite 
Radios, but assigned a single voice satellite communications (SATCOM) channel shared 
by the entire CJSOTE within the theater and reserved for command, emergencies, or units 
in contact. The SATCOM radios were data capable with ruggedized laptops allowing 
Special Forces teams to send free text messages. This is significant, because despite not 
having an actual chat tool, units used the free text messaging capability to provide an 
improvised chat (more specifically instant messaging) functionality to fill the C2 gap. 
Army Special Forces firebases always had SATCOM connectivity with the text 
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messaging capability running and most business within the firebases was conducted by 
text conversations. While on the move during operations, teams were contacted over 
voice SATCOM and told to come up on the laptops for text messaging. 


One Special Forces Operational Detachment A (ODA) Commander 
recounted how this text-based communications capability aided operations. His ODA 
team was operating in an area where another unit’s mission fell through. His team 
received a voice call over SATCOM to come up on SATCOM data. With the text 
messaging capability he received a fragmentary order (FRAGO), acknowledged receipt, 
and discussed operational details. This improvised chat capability allowed the ODA 
team to execute the FRAGO much more rapidly than if a voice exchange had taken place. 
The ODA executed a cordon and search of a small village, resulting in two personnel 
under control (PUCs - enemy combatants; not prisoners of war) and capture of a 
weapons cache. The SITREP was sent to higher headquarters using the improvised chat 
capability, which would read it and start asking questions back. 

In another case, after mission completion, an ODA team sent a SITREP to 
higher headquarters using the improvised chat. The CJSOTF replied immediately 
concerning the PUCs the ODA had in custody. The ODA Commander replied, telling the 
CJSOTF when and where the Afghan Militia Forces (AMF) captured the PUCs, passed 
their descriptions, what PUCl and PUC2 said when debriefed, and that they had dual 
identification that did not check out. He also reported that they had weapons and were 
seen leaving a large cache with rifle propelled grenades (RPGs), Soviet style mines, 
detonation cord, etc. Information continued to be passed and then the CJSOTF directed 
the ODA team to maintain positive control of the PUCs and document all information 
about them. The total, detailed exchange required only a couple of minutes with the 
improvised chat. 

e. UAV Operations 

Sixth Marine Regiment used chat for global collaboration during Direct 
Support (DS) UAV operations. Sixth Marines, in Afghanistan for OEF, used chat to 
communicate with the Air Force UAV pilot and payload operator at Nellis Air Force 
Base (AFB), Nevada. During the UAV mission, the regiment requested specific actions 
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by the pilot and the payload operator in real time, while the Army Colleetion Manager for 
the CJTF monitored the chat room and tracked the mission. 

Second Battalion, Fifth Marines (2/5) used chat for UAV operations in 
OIF I and OIF II. Chat allowed 2/5 to direct the pilot and the payload operator during the 
mission and disseminate what the UAV was seeing. 

Marine Unmanned Aerial Vehicle Squadron Two (VMU-2) used chat 
extensively during OIF II and OIF III. Chat was used for UAV support to targeting, 
strike execution, and close air support (CAS) for units supported by VMU-2 UAVs. 

/. Targeting 

Third Infantry Division (SID) OIF targeting vignette: 

Baghdad...watched a BM-2I moved to outskirts of city S/SE; fires 3-5 
rounds, returns to city. SID following on UAV (in DS to DIV) and tracks 
launcher back into the city where launcher links with re-supply vehicle. 

96D SGT HOLT, Paul is watching on GBS [Global Broadcast System] 
monitor and is in mIRC Chat talking to Air Force FAC [Forward Air 
Controller] while the Targeting Officer, ILT Elizabeth Snyder is talking to 
CEACC [Combined Eorce Air Component Commander] in parallel. SGT 
Holt verifies grid and confirms target. Air force destroys target. Total 
time of sensing to shooter - 20 minutes...would have been earlier but he 
[BM-21] was driving in residential area...ACE did not see the re-supply 
vehicle in the field he drove into until the BM-21 stopped at its hide site 
(CALL 2003). 

The US Air Eorce’s 421st Lighter Squadron used SIPRNET-based chat for 
time sensitive targeting. This allowed collaboration with the Combined Air Operations 
Center (CAOC) at A1 Udeid Airbase for questions on targets, the ATO, or strike-related 
questions and coordination with parallel agencies. Dynamic targeting and strikes were 
also facilitated by chat. Lor example, a ground unit calls in a troops in contact (TIC) 
report, the information flows to squadron operations, which can then re-task aircraft to 
collect targeting intelligence or to execute CAS. This applied to situations beyond troops 
in contact like pipeline attacks or suspicious activity where jets from the 421st would be 
re-tasked to a specific target for surveillance. The squadron monitored the mission and 
watched the CAOC direct events. Monitoring the mission in chat aided in debrief 
preparation and expedited the debrief/mission report process once the pilots returned. 
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g. Close Air Support 

During OIF the 4th Air Support Operations Group (4th ASOG) attaehed to 
the US Army V Corps used ehat eontinuously for CAS exeeution among US Army V 
Corps, Coalition Land Forees Component Command (CFLCC), Combined Foree Air 
Component Commander (CFACC), and Marine Expeditionary Forees (MEF). They 
provided C2 for all V Corps CAS missions and eonsidered ehat absolutely eritieal to 
mission aeeomplishment beeause it was the most expedient method of eommunieation 
and allowed real-time eollaboration. 

Chat was used by 4th ASOG to task UAVs (Predator, Hunter, Shadow, 
Global Hawk) and other assets to eolleet and disseminate intelligenee to Taetieal Air 
Control Parties (TACP), CAS aireraft, V Corps ACE (Analysis and Control Element), 
and any other units requiring the information for CAS exeeution. Chat was further used 
for de-eonfliotion of CAS, joint fire support, and of CAS and UAV airspaee, real-time, 
within V Corps, MEE, CEACC, UAV units, and Air Eoree Distributed Ground Stations 
(AE DGS) - the people exploiting UAV imagery. 

The 22d MEU (SOC) in Afghanistan for OEE eoordinated details of 
emergeney CAS tasking over ehat, mainly for the requesting, alloeating, and tasking 
stages. The senior wateh offieer would post TIC reports in the main ehat room and CAS 
details would be worked out in the same room or in private ehat with liaison offieers at 
CJTE-76 ACCE. Changes to CAS were diseussed in ehat before and during the mission. 
Changes would be sent to eoordinating ageneies in ehat and from there radioed to 
airborne aireraft. The Marine Direet Air Support Center (DASC) used ehat to update 
what aireraft would exeeute CAS and their status (i.e. tanking, time remaining on 
station). 

h. Combat Recovery 

The 421st Tighter Squadron used ehat extensively in every eombat seareh 
and reseue (CSAR) mission during OIE. Chat was the primary tool used with UHEA^HE 
voiee eireuits for airspaee de-eonflietion and for supporting arms and elose air support 
(CAS) eoordination during eombat reeovery missions. The 24th MEU (SOC) used ehat 
during OIE I and OIE II to request aireraft for eombat reeovery missions and to pass 
information. 
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Helicopter Anti-Submarine Squadron 3 (HS-3 “TRIDENTS”) embarked 
aboard the USS ENTERPRISE (CVN-65) for OEE, used chat for joint CSAR. The 
TRIDENTS supported joint maritime CSAR and CSAR for western Pakistan and 
southern Afghanistan. 

Chat was also used for search and rescue missions (SAR) in the United 
States. Again, HS-3 used chat, this time to coordinate a joint Navy and Coast Guard 
maritime rescue off of North Carolina. 

i. Medical Evacuation 

Chat played a significant role in the medical evacuation (MEDEVAC) 
process around the world and across the spectrum of military operations. Chat was used 
in Afghanistan during OEE by CITE-180 to coordinate MEDEVACS of combat and non¬ 
combat casualties. The CITE also used chat to clear fires in the MEDEVAC airspace. 
The 22nd MEU (SOC) also used chat for MEDEVACS as part of CJTE-180 and later 
CJTE-76 in Afghanistan during OEE. Units posted MEDEVAC 9-lines (standardized 
request format) to the main chat room and the MEU would either task their organic air 
assets with the MEDEVAC over chat or use chat to request support from higher 
headquarters. When Third Battalion, Sixth Marines (3/6) received a unit in contact 
report they immediately monitored the MEDEVAC preparations in the aviation brigade’s 
chat room and passed MEDEVAC information to the CITE in chat. 

During two deployments to Iraq, Helicopter Marine Heavy Squadron-465 
(HMH-465) received tasking from higher to execute MEDEVACs. The 9-line 
(MEDEVAC) information was passed to the squadron over chat and then handed to the 
MEDEVAC pilot just prior to launch. This information included grid coordinates, radio 
frequencies, what to expect at the landing zone (EZ), etc. 

Chat was also used to coordinate MEDEVACs during Disaster Relief 
Operations. The USS IWO JIMA used chat to coordinate MEDEVACs as part of JTE- 
Katrina 

j. Meteorological and Oceanographic Support to Joint Operations 

Meteorological and oceanographic (METOC) forecasting support affects 

joint and combined operations across the full military spectrum. Chat has proven a vital 
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tool for coordinating weather foreeasts for various theaters. Southern Command METOC 
(J332) personnel used ehat during Operation SECURE TOMORROW to eoordinate 
weather support for Royal Canadian Air Eoree helicopters flying in-and-around Port-au- 
Prince, Haiti. 

The 28th Operational Weather Squadron (OWS) at Shaw Air Eoree Base 
(AEB), South Carolina used ehat to support OEE/OIE. With chat they conducted foreeast 
eoordination, tailoring, and dissemination to in-theater units from one platform. 

The laek of weather data in Iraq eomplieated foreeasting efforts, but with 
ehat METOC units at the CAOC, A1 Udeid Airbase, Qatar and others spread throughout 
Iraq eould eollaborate with eaeh other and with the regional foreeasting eenter at Shaw 
AEB. The eollaboration enabled by chat allowed them to develop one general foreeast 
for the entire theater. 

US Central Air Eorees Command (USCENTAE) METOC used ehat to 
provide weather support to all four serviees in both the OEE and OIE theaters. Chat was 
used to eommunieate with units in the field and discuss weather products. These units in 
the field were able to aet as “eyes forward” feeding weather information baek to 
USCENTAE that was integral to their product construction. They found chat use 
provided a more eonstant and reliable flow of information than other available methods 
(i.e. phone, email). With chat they were able to provide the best-tailored weather 
products to units because ehat provided aeeess to most units, enabling effieient, multi¬ 
person diseussions that affeeted large groups of people. The time-sensitivity of some 
weather produets was met with ehat, whieh proved the fastest and most reliable method 
for their dissemination. 

2. J-2 Intelligence 

a. Counterintelligence 

Members of the Air Eoree Offiee of Speeial Investigations (AEOSI) 
Detaehment 105, Robins AEB, Georgia provide real time eounterintelligenee support in 
the Metro-Atlanta and middle Georgia AOR. They used chat for real-time diseussion 
about intelligence and foree proteetion information with the Clayton County Sheriffs 
Offiee, Georgia Intelligenee Sharing Analysis Center (GISAC) and other loeal law 
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enforcement agencies. Chat allowed AFOSI personnel to set up target areas to work 
sources and liaison with any nearby Air Force interests. Chat is used for planning and 
execution because of its ease of use. 

b. National Intelligence Support to Joint Operations 
The US Air Force’s 55th Wing provided national intelligence support to 
OFF and OIF with their RC-135 Rivet Joint (intelligence, surveillance, reconnaissance 
platform) aircraft. Chat was vital for real time re-tasking, target sharing, and indications 
and warning for ground elements. More efficient than voice, chat allowed real-time 
connectivity with everybody at once, including joint and combined forces in theater and 
reach back to various stateside agencies. The most common use of chat was for 
coordination between on-station RC-135 Rivet Joints, the CAOC, and strike aircraft and 
similar coordination with ground elements 
B. USE ASSESSMENT 

There are many reasons warfighters choose to use chat. When answering the 
question of “why chat?” numerous attributes were given. Many of these attributes were 
synonymous, while some grouped well into subsets of others. For productive discussion 
we wanted to refine the reasons given for chat use into common language, so we combine 
and reduce them to the top five reasons for use. 

1. Faster 

Faster applies the chat users’ ability to request, send, and receive large amounts of 
information in real-time. This is particularly useful for tasking. Tasks sent in chat are 
immediately available for the recipient unit to read once you send it. Various members of 
the unit tasked can immediately read it and begin task clarification and refinement within 
their respective functional areas using chat. Subordinate and supporting units can also 
monitor these taskings and begin coordination and parallel planning, compressing the 
planning process and ultimately the time to prepare for mission execution. Tasking 
within chat happens so fast that some feel the chain of command is bypassed because 
very often, when higher headquarters tasks the intermediate headquarters, the tactical 
units already see the tasking and begin working. However; many units leverage this 
speed to generate operational tempo, particularly in the dynamic counterinsurgent and 
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disaster relief environments. Users report that ehat aids in speeding up eommanders’ 
OODA Loops (Observe, Orient, Decide, Act). 

Units are re-tasked fast with chat. The use cases demonstrated this: CAS aircraft 
in the air, UAVs, Special Forces teams - these, and others, can all be dynamically tasked 
during the mission because of the speed generated with chat. 

Faster also applies to the transmission time and turn around times of other 
systems. There is no need to draft a radio message, hand it to the Radio Watch 
Supervisor, and wait for the operator to send it. Chat does not need to be read line by line 
like a radio message and copied down at the other end. You do not have to retransmit 
sections of the message or read back sections to ensure understanding like you do with 
radio. Even if two actuals (commanders or staff officers) are talking to each other they 
(or somebody) need to take notes as grids, times, target numbers and the like are passed. 
This is unnecessary with chat, generating speed and making it faster. 

Finding a phone number, dialing it, waiting for an answer, and then waiting for 
the person you actually want to talk too to get on the line can be long process. They may 
not be there requiring you to work with somebody else or even leave a message. If they 
are there you have to read grids, targets, etc back and forth and copy them down. Again, 
we see how chat generates speed. 

Users point out that even email, file transfer, and web-based forms are too slow. 
They spend time looking up email addresses and websites. They have to wait on the 
distant end to read their requests and answer back. This is slower than chat. Now 
imagine you need to send the information to ten people in ten different units or agencies. 

Chat is fast because it generates operational tempo. The increased flow of 
information across units, functions, operational boundaries, and services increase speed 
in planning and speed in execution. 

2. Easy 

Easy does include convenience, but easy helps make chat fast. With chat, users 
have a list of who is in the room. All users in the room can read the chat thread (unless 
sent private) so users do not need to look up email addresses, phone numbers, or radio 
network IDs. 
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With many users in the room, no multiple radio calls, emails, or phone calls need 
to be made. Collaboration is the norm in chat, no need to coordinate it like white 
boarding sessions, conference calls, or video teleconferences. The ability to monitor 
multiple rooms means that you can monitor multiple missions of various units. Users 
feel it is easy to build and maintain their situational awareness this way. 

Chat uses plain language that is easier to converse in and understand than radio 
procedure, for example. Chat automatically creates a record of the conversation in the 
room that you can refer back to for clarification or even review later for after action 
items. Some chat tools can log their conversations so there is a record beyond what is 
currently displayed in the room. 

Users said that chat was easier than other communication systems like tactical 
radio networks, or secure telephones (STU-III/STE). Some noted that is easier to type in 
Mission Oriented Protective Posture (MOPP) gear with a gas mask than talk on a radio or 
phone. 

One must be wary of the convenience factor, because chat may not be the best 
tool for all situations, but is used anyway. For instance, a request that a user needs fdled 
in hours or days is probably better sent over email than in chat. Inundating chat with 
non-time sensitive information creates clutter, confusion, and makes chat slower and 
harder to use. 

3. Availability 

This attribute is a composite of attributes like connectivity, reliability, stability. 
Users found (and now expect) chat to be there when other C2 systems are not. Further, 
they expect the users they want in the room 24 hours a day, 7 days a week. 

When users enter a chat room, they not only expect other users within their unit to 
be available, but “everybody else” worldwide. Users cite chat’s ability to provide a 
collaborative C2 capability between multiple garrison (headquarters) units in the 
continental US and deployed units worldwide in a single tool. This global capability is 
the minimum C2 capability expected by many warfighters interviewed. Further, users 
expect chat to provide this capability over SIPRNFT, high side (TOP SFCRFT 
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networks), and even on Non-seeure Internet Protocol Routed Network (NIPRNET) for 
coalition disaster relief operations like JTF-Katrina or Operation Unified ASSISTANCE. 

Users find that chat is available when other C2 systems are not. They reported 
that chat was the only form of communications in many cases, where units were too far 
for voice, and the available transmission systems lacked the bandwidth for larger C2 
systems. The geographic dispersion and topography of Afghanistan coupled with its lack 
of infrastructure is a perfect example. Users at Forward Operating Bases (FOBs) in 
Afghanistan during OFF reported having only a couple phone lines, which allowed only 
two concurrent phone conversations, but provided them the ability to dial in with chat 
and have several concurrent chat sessions. 

Even when there is more robust transmission systems support, these systems lack 
the bandwidth for many workstations with larger C2 systems, so warfighters limit the 
number of these and use chat to fill this capability gap. Many chat tools use very little 
bandwidth allowing more users to use chat than other C2 systems; these tools avoid 
latency and timing hits on the network. When the network experiences issues and 
capabilities degrade (intentionally or not), text-based chat is the minimum “gotta have” 
and generally available long after the other C2 systems have stopped functioning. 

Users know chat will be available and reliable and work that into their C4 plans. 
When deployed, the first data system up in many cases is chat. Chat is then used to 
coordinate bringing up and establishing connectivity with the other C2 systems. Chat is 
the user’s troubleshooting tool of choice, used for the global troubleshooting of SECRET 
and high side systems in theater, across theaters, and even with contractors stateside. 

4. Efficient 

Users like how chat allows them to send more data with far less expenditure of 
time and effort. For example, various reports can be sent in chat while the user continues 
to look at the Common Operating Picture (COP); map software, or other tools. They can 
monitor chat while working in these tools. 

Stated before, chat’s capability for users to access multiple rooms and have 
conversations with multiple people with no extra effort is a capability strongly embraced 
by the warfighter. Returning to sending reports, users send reports to large groups of 
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people with the same effort it takes to send it to one. While reports can certainly be sent 
by email, chat allows other users who may not doctrinally need the report but are 
monitoring the chat room to receive it, increasing their SA at no additional cost in time or 
effort. Chat allows users to be proactive rather than reactive within and across 
organizations. One should note that this could lead to the dreaded overreact, or proactive 
action on bad information, and points to the need for good business rules. Some, 
organizations, like USCENTAF, have already developed chat business rules. 

Users like how chat facilitates understanding with written text. Time and effort is 
saved from repeating questions because you have it written before you - if information is 
missing users can identify it faster. This persistence is not provided as efficiently with 
other C2 means that use paper logs or even digital methods like email where users waste 
time rifling through email chains. 

Chat allows a division of labor between units throughout the world. Preparation 
of the forecasts by the METOC in the use cases is a perfect example. Deployed units 
drawing upon other units globally can experience economies of scale. 

Technically, the operation of chat should breed efficiency. We already mentioned 
bandwidth and latency, but with chat there is no retransmission of radio traffic or 
stepping on each, no repeated phone calls back and forth. This creates efficiency 
elsewhere; reduced radio traffic freeing voice nets for urgent tactical traffic, phones free 
for when needed, less load on email servers. 

5. Required 

This attribute is interesting and foreshadows some of the issues in the next section 
on chat risks. If most business is done in chat, then you need chat to do business. Users 
feel that without chat, their SA would be diminished and information dissemination and 
coordination would be a struggle. In cases where chat did become unavailable, users did 
find themselves behind the power curve trying to use other methods (particularly voice) 
because their business practices had actually changed (note that the business rules did not 
change with the practices). 

Requirement goes beyond capability when you consider combined operations. 
The HMCS Toronto’s experience demonstrated that chat is required during coalition 
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operations, but not everybody is always on the same ehat. The Canadian ship’s eall for a 
single chat was echoed by Expeditionary Strike Group Six (ESG-6). The ESG noted that 
forces under tactical control of coalition forces should use a collation chat solution (in 
this case CENTRIX) where you would normally use SIPRNET-based chat (ESG-6 2005). 
The counterintelligence use case demonstrated how a military unit was required to use 
chat with civil authorities to prosecute their force protection mission. 

The attribute “required” goes back to the problem statement of this paper. There 
are numerous chat tools in use that do not interoperate. There are major issues during 
combined operations. If we believe, as users claim, chat is a required tool for 
warfighting, we need representation and program support to facilitate standardization and 
interoperability. 

C. CHAT RISKS 

Chat, like all military C2 systems, has associated internal and external risks that 
must be mitigated to an acceptable level. The factors creating risk are technical, 
organizational, and related to HSI. These risks affect the baseline Information Assurance 
(lA) requirements of confidentiality, availability, and integrity set forth in DOD Directive 
8500.1: lA (2002) and DOD Instruction 8500.2: lA Implementation (2003). 

1. External Risks 

The external risks are those to critical infrastructure and parallel to the generalized 
threats to the GIG and other national (coalition partners) networks (JCS and DISA 2005). 
The peer to peer aspect (P2P) of chat includes risk, and was banned initially before being 
authorized conditional to adherence with the appropriate lA practices and Designated 
Approving Authority (DAA) approval (Wells 2004a and Wells 2004b). This does not 
mean the risks were mitigated, but only accepted. 

2. Internal Risks 
a. Integrity 

Internal risks are the greatest, with 75 - 80 percent of all network attacks 
and loss of proprietary or classified information attributed to internal, authorized users 
(JCS and DISA 2005). Research has shown chat use can lead to a group phenomenon 
termed sense of security, where things happen to quickly in virtual collaboration and 
lead to premature decisions (Wainfan, Eynne and Davis 2004). This impacts the integrity 
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of information in chat. The MEF Tactical Air Control Center (TACC) experienced 
information integrity issues within chat rooms during OIF ranging from erroneous grid 
coordinates, transposed numbers for times, and even an incorrect order to execute a 
Tactical Recovery of Aircraft and Personnel mission (TRAP) (Glasgow 2003). 

b. Confidentiality 

With most chat residing on the SIPRNET, confidentiality is less at risk by 
external disclosure than by disclosure to or lack of disclosure from internal users. Many 
user IDs used in chat are functional, making it difficult to know who is really in the chat 
room. Some consider that human nature creates risk, with users lying about their 
identity, sharing accounts, failing to log out, account compromise, and somebody looking 
over your shoulder or even “sniffing” your conversation (JCS and DISA 2005). 
Malicious software may be received and activated by users if coming from a “person” 
they are comfortable with in chat (JCS and DISA 2005). 

c. Availability 

Availability is impacted by several factors, with bandwidth the major 
factor affecting units’ ability to use chat, particularly the chat capabilities of larger 
collaboration suites. During Operation UNIFIED ASSISTANCE, initial use of IWS chat 
by deployed METOC teams failed due to insufficient bandwidth, forcing all units 
supporting the Joint Operations Area Forecast (JOAF) to be switched to a smaller, less 
bandwidth intensive chat tool (Hey 2005; Symes 2005). A similar instance happened to 
CJTF-Haiti METOC personnel from USSOUTHCOM using the DCTS chat software, 
which failed due to bandwidth and latency shortfalls (Kampmeyer 2004). The Stryker 
Combat Teams of 3rd Brigade, 2ID used chat in Iraq to great effect; however, they too, 
suffered bandwidth-related availability issues (3rd Brigade, 2ID 2004). 

3. Tactical Information Exchange and Situational Awareness 
Finally, chat can actually affect the units’ tactical operations and situational 
awareness. The Combined Anti-Armor Teams (CAAT) of Weapons Company, Third 
Battalion, Fourth Marines struggled to receive important information in Iraq. Important 
tactical information, TICs, be on the lookout (BOFO) reports, friendly troop movements, 
and more was sent in chat, not tactical radio networks leaving those units without chat out 
of the loop (Butler 2005a; 2005b). Recent research into human performance issues for 
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supervisory control of the Navy’s new Tactical Tomahawk missile, reported by 
Cummings (2005) made the unexpected discovery that many subjects fixated on the chat 
interface and ignored the task of retargeting missiles in urgent situations. The experiment 
subjects were repeatedly instructed that retargeting was their primary mission; however, 
they continued to fixate on chat answering all queries before the retargeting problems 
(Cummings 2005). The Command, Control, Communications, Computers, and Combat 
Systems Officer (C50) of the USS I WO JIM A, while standing watch noted that the 
volume of chat traffic inundated users with information. This information deluge 
consisted of legitimate traffic and spurious requests from users requesting information in 
the names of higher headquarters units. When the C50 started calling these users based 
off their profile information, he discovered they were lower ranking personnel collecting 
information for briefs and reports. In most cases the information had already been passed 
and chat was being used because it proved easier to ask for the information directly than 
look it up. 

Significant research opportunity exists looking into managing the risk of chat use. 
Technical solutions abound, but standardization and the ability to integrate cross-domain 
within our own forces, let alone with coalition partners, remain problems of policy and 
organizational behavior. Organizational change must be coupled with HSI research to 
ensure success. Only by addressing risk as a dependency of technical, organizational, 
and HSI issues will we reach an acceptable level of risk for the DAA. 

D. REQUIREMENTS 

This thesis developed a framework for categorizing and developing future chat 
requirements. The framework consists of four categories: Functionality, Information 
Assurance, Scalability, and Interoperability. 

These categories were derived through study and discourse on the compiled, 
explicitly stated service and select COCOM and OGA text-based chat requirements. This 
was guided by the concepts set forth and capabilities called for in the joint and service 
warfighting concepts previously discussed. Appendix D compares the compiled, 
explicitly stated text-based chat requirements by service. Appendix E compares the 
compiled, explicitly stated text-based chat requirements by COCOM and OGA. 
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The focus of effort to develop the framework for considering chat requirements 
was on the definition of C2 capability gaps filled by chat and the identification of 
capability needs. This top down, systems engineering approach focused on chat lessons 
learned and stakeholders’ required capabilities to broadly define common requirement 
categories and high-level requirements. This is crucial because while many organizations 
listed the same gaps and requirements, they had very different ideas of what those 
requirements meant to them (i.e. a bandwidth austere environment to the Navy is very 
different from that of the Air Force). 

1. Functional 

The word function, as it regards to technology, often lacks a commonly 
understood definition. We define it here as: “the action for which a person or thing is 
specially fitted or used or for which a thing exists” (Merriam-Webster Online, s.v. 
“function”). This requirements category addresses those requirements that contribute to 
the desired core capability (core function); real-time text-based chat. 

A key question when considering functional requirements is: “which requirements 
directly contribute to the core function and which requirements add capability not 
required for the core function?” For example, the “participate in multiple concurrent chat 
sessions” requirement materially contributes to the core function. The “hyperlinks” and 
“file transfer” requirements, while useful, are not required to achieve the core function. 
This is evident in Appendices D and E by what requirements the organizations do or do 
not agree on. Eight of eight organizations agree that the ability to participate in multiple 
concurrent chat sessions is required, suggesting this is a bond fide core requirement. 
Only one organization lists the “hyperlinks” requirement and only two organizations lists 
the “file transfer” requirement, suggesting that these are not required to achieve the core 
function of text-based chat. Table 13 lists the consolidated functional requirements from 
Appendices D and E. 


48 



Table 13. Consolidated functional requirements 
Functional Requirements 
(* denotes a core requirement) 

1. Participate in Multiple Concurrent Chat Sessions* 

2. Display Each Chat Session as Separate Window 

3. Persistent Rooms & Transitory Rooms* 

4. Room Access Configurable by Users 

5. Automatic Reconnect & Rejoin Rooms* 

6. Thread Population/Repopulation* 

7. Private Chat "Whisper"* 

8. One-to-One IM (P2P) 

9. Off-line Messaging 

10. User Configured System Alerts 

11. Suppress System Event Messages 

12. Text Copying* 

13. Text Entering* 

14. Text Display* 

15. Text Retention in Workspace* 

16. Hyperlinks 

17. Foreign Language Text Translation 

18. File Transfer 

19. Portal Capable 

20. Web Client 

21. Presence Awareness/Active Directory* 

22. Naming Conventions Identify Functional Position* 

23. Multiple Naming Conventions 

24. Multiple User Types 

25. Distribution Group Mgmt System for Users 

26. Date/Time Stamp* 

27. Chat Logging* 

28. User Access to Chat Logs* 

30. Interrupt Sessions 


Recall the use assessment section in this chapter. Under easy, we noted that easy 
includes convenience. The non-core requirements listed by stakeholders represent 
conveniences. Just as inundating chat with non-time sensitive information makes chat 
slower and harder to use, so does including non-core requirements. These non-core 
requirements impact other reasons warfighters use chat, that it is: faster, available, and 
efficient. This does not mean these non-core requirements are not valid, but they must be 
addressed carefully as they may adversely impact the reasons chat works for C2. The 
high-level scalability requirements, as defined by this research, demonstrate how many of 
these functional issues may be addressed. 
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2. Information Assurance 

Information assurance requirements seek to provide the eapability to ensure the 
integrity, the eonfidentiality, and the availability of the chat tool. These requirements 
must aeeount for, manage, and mitigate the risks assoeiated with chat use. This ineludes 
the risks discussed in this thesis applied to various network types: seeure (SIPRNET), 
non-seeure (NIPRNET), eoalition, and ad-hoe (i.e. disaster relief). Table 14 lists the 
eonsolidated lA requirements from Appendiees D and E. 


Table 14. Consolidated information assuranee requi rements 
Information Assurance Requirements 

1. Login and User Authentication 

2. Access Control 

3. User Authentication by Active Directory 

4. Unique ID for all users worldwide 

5. PKI Enabled (DOD Common Access Card) 

6. Provide Encryption 

7. Network Security Tools 

8. Cross Security Domain Functionality 

9. Multi-Level Security Operation 

10. Cross Security Domain Functionality _ 


Some disparities exist between organizations regarding the lA requirements and 
are annotated in Appendices D and E. Three major areas that differ are: login and user 
authentieation (a derived requirement from the requirements: aceess, user authentieation 
via aetive direetory, and PKI enabled from Appendiees D and E), eross seeurity domain 
funetionality, and multi-level seeurity operation. These requirements are tied very tightly 
to requirements in the funetionality and scalability categories and a review of Appendiees 
D and E demonstrates the eomplexity of this interrelationship and the variation of views. 
After eareful analysis, the differenees were synthesized to develop three requirements 
that satisfy the disparate ones in Appendiees D and E. Note the significant difference 
between the definition of eross security domain and multi-level seeurity, whieh is a 
perfeet example of how various organizations used terminology differently in Appendiees 
D and E. 
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a. Login and User Authentication 

Provide login and authentication process with variable settings using 
active directory. Access to network is not consent for access to chat system. Two 
authentication options; simple authentication (username and password) and strong 
authentication with username, password, and token (DOD Common Access Card). 

b. Cross Security Domain Functionality 

The chat tool can be used across equivalent level security domains with 
coalition partners, eliminating the need for multiple, redundant chat tools. Cross domain 
access is limited to that required for communication between chat tools (i.e. for 
SIPRNET we allow access to the chat tool, but prevent any further network access per 
policy). 

c. Multi-Level Security Operation 

The chat tool can be used across different level security domains (i.e. 
NIPRNET chat users to collaborate with SIPRNET chat users in a single tool). This 
incurs significantly more risk than cross security domain functionality. 

3. Scalability 

These requirements address a proposed chat tool’s ability to rapidly scale in 
response to stakeholders’ changing needs. The stakeholders in Appendices D and E have 
different need sets based on missions, organization, and doctrine. Table 15 lists the 
consolidated scalability requirements from Appendices D and E. 


Table 15. Consolidated scalability requirements 
Scalability Requirements 

1. Austere Network Operation 

2. Low Overhead Login Proeess 

3. Use Client without Server 

4. Distributed Arehiteeture 

5. Number of Coneurrent Chat Sessions 

6. Number of Coneurrent Users 

7. Speeified Quality of Serviee 


The different need sets of stakeholders makes reaching agreement regarding these 
requirements difficult. The at-sea Navy sails with the C2 capabilities organic to the ships 

underway, which currently leave little room to scale. The Marine Corps’s rapid task 
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organization inherent to the MAGTF results in very fluid requirements and C2 
arehitectures. The scalability requirements, as deflned by these services in Appendices D 
and E, attempt to address each service’s needs. After the reader reviews Appendices D 
and E, ask “do these requirements address Navy and Marine needs when a Marine unit 
embarks upon naval shipping?” 

We acknowledge the inherent difficulty in decomposing the requirements, so we 
developed a high-level definition for each. These definitions serve as a common point of 
departure for future researchers and stakeholders as they decompose these requirements 
further. They also address implementation many of the non-core functional requirements 
discussed earlier. 

a. Austere Network Operation 

The chat tool must be capable of operating on austere networks where low 
bandwidth and high latency are common. Elsers must be able to configure functionality 
as required to maintain the core text-based chat capability from high-level headquarters to 
the dismounted, tactical user. 

b. Low Overhead Login Process 

The numerous connects and reconnects of chat users, coupled with 
authentication, represent overhead paid in bandwidth. An efficient login and 
authentication process coupled with the alternative of light authentication support tactical 
users in austere network environments. 

c. Use Client without Server 

The IM functionality of the chat tool is sufficiently robust to allow its use 
as the primary means of text communications for units or missions with no chat server 
planned for or available. Tactical users with extremely low bandwidth may use IM to 
communicate with higher headquarters, who may then in turn inject the information into 
the chat system. 

d. Distributed Architecture 

Earger units would maintain their own chat server or servers that are 
linked together globally. This distributed architecture supports more users. Survivability 
increases since units no longer rely on a single central server (server cluster); if the 
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central link goes down they eontinue to chat on their loeal server(s) until the link is 
restored. 

e. Number of Concurrent Chat Sessions 

Administrators ean set the maximum number of eoneurrent ehat sessions 
allowed by the ehat elients based on network eonditions or SA eonsiderations (see Chat 
Risks Chapter 3). Chat servers support of eoneurrent ehat rooms should only be limited 
by mission requirements, chat protocols, or network eonditions. Current OEF/OIF 
operational numbers range from II MFF’s 10 IRC Servers supporting approximately 84 
ehat ehannels to the 350-400 chat channels supported by the Fifth Fleet’s four ehat 
servers (Shapiro 2005; Banerjee 2005; Heacox, Moore, Morrison, and Yturralde 2004). 

/. Number of Concurrent Users 

Chat servers support of eoneurrent ehat users should only be limited by 
mission requirements, ehat protoeols, or network eonditions. Using the example from 
eoneurrent ehat sessions: numbers of eoneurrent users range from over 900 on II MFF’s 
servers to the 2500-3000 on Fifth Fleet’s servers (Shapiro 2005; Banerjee 2005; Heaeox, 
Moore, Morrison, and Yturralde 2004). 

g. Specified Quality of Service 

Chat servers and elients are configurable to ensure continued deliveranee 
of aeeeptable eonneetivity and reliability based on faetors related to network topology 
and eommunieation transmission systems. Items that may be eonfigured inelude 
funetionality, the number of eoneurrent chat sessions, and the number of eoneurrent 
users. 

4. Interoperability 

The interoperability requirements are reasonably self explanatory and Appendiees 
D and E show that stakeholders eiting them are in relative agreement on what they want 
teehnieally. The stakeholders in Appendiees D and E take a teehnical approach to 
interoperability. We want to explore the other aspeets of interoperability as it relates to 
chat. Even when everything is teehnieally perfect, there are human and organizational 
faetors that still prevent true interoperability of ehat. Table 16 lists the eonsolidated 
interoperability requirements from Appendiees D and E. 
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Table 16. Consolidated interoperability requirements 
Interoperability Requirements 

1. DOD Standards 

2. Open Standard 

3. Multi-Platform Clients 

4. Interoperate with Existing Collaboration 

Systems 

5. Interoperate With Offiee Automation Tools 

Chat interoperability must include doctrine. Chat continues to change the way 
doctrine is executed across units and services. Not only is chat specific doctrine 
necessary, but warfighting doctrine must address chat as it does other C2 systems. One 
example comes from the Expeditionary Warfare Training Group Atlantic (EWTGLANT) 
AAR dated 15 June 2006. Jamison (2005) noted that Battalion Eire Support Coordination 
Center Personnel (ESCC), Battalion Watch Officers, and Operations Chiefs used chat to 
coordinate instead of doctrinal radio nets. The recommendation was to formalize chat 
into fire support doctrine (Marine Corps Warfighting Publication 3-16: Eire Support 
Coordination in the Ground Combat Element) as a new C2 method, emphasizing who 
guards, monitors, and serves as net control (Jamison 2005). 

Training is another part of chat interoperability. Many chat users and maintainers 
are unaware that current chat tools already fulfill some chat requirements called for in 
Appendices D and E. The ad hoc nature of chat precludes formal training. Chat 
experimentation during TW 05 proved that training was necessary for Universal Chat 
client (UCC) users, Multi-Eevel (ME) Chat users, and Persistent War Room (PWR) 
users, to become aware these chat tools’ features and understand how to use them (TW05 
Analysis Report 2006). 

E. TRIDENT WARRIOR 05 

I. Information Management Chat Experiment Results Analysis 

This section reports the TW05 experiment results and conclusion for the high- 
level objective “Define Navy EORCEnet DOTMEPE requirements for a maritime chat 
tool.” The experiment objectives are listed in Table 17 and the experiment results by 
objective are listed in Table 18. 
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Table 17. 

TRIDENT WARRIOR 05 Information Management chat objectives 

Objective 2 

Universal Chat Client (UCC) - Assess the eapability of UCC to fill the doeumented gaps 
that eurrently exist in eurrent maritime ehat protoeols used throughout the US Navy. 

Objective 3 

Uber Chat - Does Tiber Chat provide funetionality that fills identified gaps in eurrent 
maritime ehat protoeols? 

Objective 4 

Extensible Messaging and Presence Protocol (XMPP) - Does XMPP provide 
funetionality that fills identified gaps in eurrent maritime ehat tools? 

Objective 5 

Multi-Level Chat (ML Chat) - Does ML Chat’s unique funetionality of ehatting aeross 
two or more domains provide the funetionality neeessary for Navy Maritime Chat? 

Objective 6 

Persistent War Room (PWR) - Will PWR and Chat Logging operate over lower 
bandwidth subnets and provide the operator ready aeeess to ehat funetions and supporting 
information as well as arehived ehat logs? 

Objective 8 

Distributed Chat Architecture (DCA) - Compare the proposed DCA (hub and leaf) to 
the eurrent (hub & spoke) IRC eommunieations arehiteeture. Provide a teehnieal solution 
to operator eoneems ineluding loss of situational awareness, reeonneetion to servers after 
a eommunieations outage, intra-ship text ehat eommunieations when off-ship 
eommunieations are down. 


Table 18. TRIDENT WARRIOR 05 Information Management ehat results by objective 
__ (After: TW05 Analysis Report 2006) _ 


Objective 2 

Universal Chat Client (UCC) - Uses a DCA and is suitable for maritime eoalition use 
with a number of “gap filling” features. It does not support file transfer or file sharing. It 
sueeessfully operated at low bandwidth with a P-3C using HF IP. 

Objective 3 

Uber Chat - Relies on a DCA and improves eollaboration. It is easy to use and baekward 
eompatible with IRC, but it ean exploit any network medium to eommunieate, thus 
offering eommunieation even without satellite link availability to the IRC server. 

Objective 4 

Extensible Messaging and Presence Protocol (XMPP) - XMPP functionality was 
successfully demonstrated in TWOS. The transmission path used was not efficient, but 
DISA designed this particular network architecture for shore establishment assessment. 

This raises the question about successful operation of XMPP with distributed 
communications architecture, which has advantages for Battle Groups at sea. 

Objective 5 

Multi-Level Chat (ML Chat) - Has a varied feature set, including the ability to cross¬ 
domains, offers much potential value for coalition use, but it lacks sophisticated HSI 
attributes, which need to be improved. 

Objective 6 

Persistent War Room (PWR) - Easily maintained fleet-wide because it runs via browser 
and Java applets, vice as a locally installed client, and operated at low bandwidths. HSI 
attributes are sound and the program contains many features desirable to coalition 
operations. 

Objective 8 

Distributed Chat Architecture (DCA) - The hub and leaf DCA was superior to 
traditional hub-and-spoke architecture because it improved SA by preserving chat history; 
servers automatically re-connected (reducing loss of chat history); bandwidth efficiency 
was increased; reliance on shore-based servers was eliminated; overall reliability was 
improved. 
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Table 19 lists the ehat tool evaluation results from TWOS by feature. 


able 19. Comparison of chat tool features (From: TWOS Analysis Report 2006) 


Feature Description 

MLC 

PWR 

Uber 

ucc 

XMPP 

Notes 

SuDDorts Time Stamps 

Y 

Y 

Y 

Y 

Y 


Automatic refresh of conversation frame (i.e., does not require 
clicking refresh button) 

Y 

Y 

Y 

Y 

Y 


Ability to "catch up" the user upon reconnect, i.e., "prefill" with 
archived messages 

N 

Y 

Y 

Y 

Y 

Uber: Cache catches user up 
automatically 

Ability to view multiple chat rooms at once without clicking 

Y 

Y 

Y 

Y 

Y 


Alerts user when a new message has arrived 

Y 

Y 

Y 

Y 

Y 


Alerts when user (self) has lost connection 

N 

Y 

Y 

Y 

Y 


Streamlined login process (login under one minute) 

Y 

Y 

Y 

Y 

Y 


Logging capability 

Y 

Y 

Y 

Y 

Y 

UCC has an independent appliation 
called Universal Chat Logger 

Uber: can save as .loo file 

Ability to recall last 20 messages, last 2 days, etc. 

TBD 

Y 

Y 

Y 

Y 


Archieved Log includes date and time stamp 

Y 

Y 

Y 

Y 

Y 


Ability to send to only one user (whisper / private chat) 

disabled 

Y 

Y 

Y 

Y 


Supports 'Broadcast topic' feature upon joining chat room. e.g. 'You 
have ioined xyz chatroom. The current topic is 123' 

Y 

Y 

Y 

Y 

Y 

Uber: user can display topic by using 
'options’ on the chat window 

Supports varying, font size, style {bold, italics), font type, and color 

TBD 

P 

P 

P 

P 

Uber: font size only 

UCC: cannot change color 

Supports collaboration between coalition partners (i.e., ability for 
NATO to talk to US Navy or ability for US to talk to mult, countries) 

Y 

N 

N 

N 

N 

MLC is CDS chat tool. All others are 
single domain. 

Supports separation between different security domains/enclaves 
(e.g.. SIPRNet. CENTRIXS. CSS) 

Y 

N 

N 

N 

N 


Supports language translation 

TBD 

TBD 

TBD 

TBD 

TBD 


Send / receive files 

N 

Y 

Y 

N 

N 

Deselected by DSIR 

Ability to hide timestamp on display (Timestamp still appears in the 
log.) 

N 

N 

Y 

Y 

N 

Relates to declutter; is separate from 
appearance in log. 

Automatic reconnect of users to rejoin chat rooms after lost 
connection 

Y 

Y 

Y 

Y 

Y 


Stored on the computer? Or does user make up a username 
upon each login 

N 

N 

Y 

N 

N 

Uber: stored on computer 

Supports white boarding, voice, and video 

N 

Y 

N 

N 

N 


Ability to create and delete chat room 

Y 

Y 

Y 

Y 

Y 



2. TWOS Conclusions and Recommendations 

The complete Navy FORCEnet DOTMLPF requirements for a maritime chat tool 
defined by the TWOS experiment results are listed Appendix F. The operational impact, 
measured impact, and recommendations for the Military Utility Assessment Board are 
consolidated in the following figures. Figure S presents these for the maritime chat tools 
and Figure 6 presents these for the DC A. 
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FoxcEn., Maritime Chat Toois 



Operational Impact: 

• Multiple chat tools operating with 
different protoools is ineffioient to 
operational communications. 

• Most of the chat tools had 
oommon funotionality, but oannot 
oommunicate with each other. 


Measured Impact: 

• UCC and Uber are IRC protocol, 
operating at approximately 4Kpbs. 

• Jabber XMPP operated at 
approximately 10Kbps. 

• PWR operated at approximately 24 
Kbps. 


• Reduced time and workload to 
prepare and maintain information. 

Successes in TWOS: 


MUA Recommendations 


• Automatio communioations 
reconneot feature of UCC, Uber 
and PWR. 

• Chat logging and arohive feature 
of UCC, Uber and PWR. 

• UCC operated successfully over 
HFIP permitting ohat 
oommunications with aircraft. 


• Forward Maritime Chat Tool 
Requirements document to 
OPNAV and Aoquisition to fill 
identified gaps in ohat tool 
functionality. 

• State as doctrine that there will be 
multiple chat technologies, 
bridged by UCC. 

• Speed acquisition of UCC. 


Figure 5. TWOS Chat Tool OAA Quad (From; Steers 2006) 


FORCEnet 


Distributed Chat Architecture 


^Operational Impact: 

H Alternative communications path 

I' 

u 



for fleet IRC. 
DCA is scalable. 


DCA is organic to Strike Group 
when operating in an EFIF-TIP 
environment. 


Measured Impact: 

• Server to Server data compressed 
over 50% 

• 75% reduction in bandwidth used for 
IRC chat communications. 


MUA Recommendations 


Successes in TWOS: 

• DCA is robust. 

• More bandwidth efficient. 

• More reliable, less downtime. 

• Eliminates NOC/Shore as single 
point of failure for ohat 
oommunications. 


• Recommend DCA as alternative IRC chat 
communications path for immediate near term 
development. 

• Continue development of DCA approach that 
will Include other chat and application 
teohnologies. 

• Use TW05 ohat server software. 


• Standardize each AOR’s server software and 
policies to integrate into a single, global 
network for SIPRNET chat. 


Figure 6. TWOS Distributed Chat Arehiteeture OAA Quad (From; Steers 2006) 
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V. CONCLUSION AND FUTURE RESEARCH 


A. CONCLUSION 

1. How is chat used across the services and warfighting functions? 

Warfighters began using chat to solve complex C2 problems across the 
warfighting functions. Chat has since migrated from a stopgap measure, the proverbial 
finger in the dike, and become one of the main real-time C2 systems used by 
Commanders and operators to execute all phases of their doctrinal missions. 

This evolution in chat use has not received official acknowledgment. Chat 
continues to fall under the umbrella of “collaboration” that obscures real usage patterns 
and prevents the appropriate support and development. 

Chat use must be captured by doctrine in two ways. First, chat must be included 
in the formalized joint and coalition C2 doctrine like other military communications 
systems used for doctrinal mission planning and execution. Second, warfighting doctrine 
across the functional areas must incorporate chat with the other C2 systems it uses. We 
must capture the changes to warfighting doctrine itself that have resulted from chat use. 
This goes back to the call by Jamison (2005) and others for doctrine to reflect the new 
realities of chat. 

2. Why is chat used across the services and warfighting functions? 

We explored the reasons why warfighters use chat. In a single sentence: 

Warfighters use chat because they have found it the best communications 
method available for real-time, simultaneous communications between 
hundreds of users in dozens of units across the services of the US, its 
coalition partners, and other governmental and non-governmental 
organizations. 

3. What risks are associated with chat use? 

There are risks associated with chat use. The technical risks are known and are 
readily mitigated with existing technology and lA practice. The human factors related to 
chat use that create risk, specifically the internal risks discussed, must be addressed 
through a combination of training, organizational structure, and process. Perhaps the 
greatest risk is if this research’s call for doctrinal incorporation of chat goes unheeded. 
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We demonstrated that chat is used for missions like CAS and fire support, missions with 
very specific communications captured in the doctrine - why leave chat out? 

4. What are the high level chat requirements? 

The core requirement is real-time, text-based chat. We must acknowledge the 
importance of text based communications, with chat at the current forefront, and provide 
the required support, research, and development. This research does not expect chat to 
look the same in 10 years; however, we must support chat in its current state so that we 
may intelligently move it forward. 

Doctrine for chat and incorporating chat is a critical requirement. Chat requires 
equivalent codified procedures to tactical voice radio (e.g., over, out, MIJI Reports 
(Meaconing, Intrusion, Jamming, and Interception)). To leave this to individual units, 
whatever the level, invites a continuation of the issues observed and addressed in this 
research. 

A development approach using the four requirement categories: functional, I A, 
scalability, and interoperability, will allow stakeholders to see the interrelationships. This 
provides a framework for the functional decomposition of the high-level requirements 
and design of a workable architecture. 

B. FOLLOW-ON RESEARCH 

1. Chat (Data) Mining 

Modern data and text mining tools applied to chat logs present unique knowledge 
discovery opportunities. The ability to conduct statistical and trend analysis on tactical 
communications provides doctrinal, technical, and HSI research opportunities. 

2. Net-Centric Enterprise Services (NCES) 

The NCES collaborative suite capabilities documents, developed by DISA, 
include a requirement for a chat capability. Research into NCES’s ability to meet 
warfighter chat requirements would be worthwhile. Does NCES meet the requirements 
of bandwidth disenfranchised units like a Marine rifle company commander, an Army 
Stryker Brigade Platoon header, an underway Navy frigate, or Coast Guard Cutter? 

3. Extensible Markup Language 

Extensible Markup Eanguage (XML) presents innovative opportunities regarding 
chat. How can XML be used for data compression, protocol translation, logging, etc? 
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4. Human Factors 

There are numerous HSI faetors regarding chat that warrant continued research. 
How does chat affect the “human in the loop”, the organization and the process? 

5. Specific Warfighting Doctrine 

In-depth research into chat use and a specific area of warfighting presents an 
exciting research opportunity. Our successful use of UAVs is directly related chat -where 
is chat use and UAV operations going? Some recommended topics for research are; 
CAS, fire support (artillery and Naval Surface Fire Support), and Marine Corps 
Distributed Operations. 

6. Information Assurance 

A researcher could develop a System Security Authorization Agreement (SSAA) 
for chat (general or a specific chat tool). The resulting document would provide an in- 
depth catalog of all risks and proposals to mitigate the risks to an acceptable level. 
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APPENDIX A. ACRONYMS 


ACE 


AFB 

AFOSI 

AMF 

AO 

AOR 

ASD (Nil) 

ASOG 

AUSCANNZUKUS 

BA JFC 
BMC2 
BOFO 
C2 

C2 JFC 
C2 JIC 
C4I 

C50 


Airborne Command Element (USAF) 

Aviation Combat Element - (USMC) 

Analysis Control Element - (USAF) 

Air Foree Base 

Air Foree Offiee of Speeial Investigations 
Afghan Militia Forees 
area of operations 
area of responsibility 

Offiee of the Assistant Secretary of Defense for 
Networks and Information Integration 
Air Support Operations Group 
Australia, Canada, New Zealand, United Kingdom, 
United States 

Battlespace Awareness Joint Functional Concept 
Battlefield Management Command and Control 
be on the lookout 
command and control 

Command and Control Joint Functional Concept 
Command and Control Joint Integrating Concept 
command, control, communications, computers, and 
intelligence 

Command, Control, Communications, Computers, 
and Combat Systems Officer - (US Navy) 


CAAT 

CAOC 

CAS 

CBA 

CCJO 

CFACC 

CFFCC 

CG 

CIO 

CJCS 

CJSOTF 

CMC 

CMO 

CNA 

CNO 

COCOM 

COMFFTFORCOMINST 

COMNAVNETWARCOM 

CONOPS 


combined anti-armor team 

combined air operations center 

close air support 

capabilities based assessment 

Capstone Concept for Joint Operations 

Combined Force Air Component Commander 

Coalition Force Fand Component Command 

Commanding General 

Chief Information Officer 

Chairman of the Joint Chiefs of Staff 

Combined Joint Special Operations Task Force 

Commandant of the Marine Corps 

civil military operations 

The Center for Naval Analyses 

Chief of Naval Operations 

combatant command 

Commander Fleet Forces Command Instruction 
Commander Naval Network Warfare Command 
concept of operations 
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COP 

common operational picture 

COWAN 

coalition wide area network 

CS 

civil support 

CSAR 

combat search and rescue 

CSG 

Carrier Strike Group 

CVN 

Multi-Purpose Aireraft Carrier (Nuelear Propulsion) 

D14 

US Coast Guard Distriet 14 

DAA 

designated approving authority 

DASC 

direet air support center 

DCA 

distributed chat architecture 

DOTS 

Defense Collaborative Tool Suite 

DISA 

Defense Information Systems Agency 

DO 

Distributed Operations 

DOD 

Department of Defense 

DOTMLPF 

Doetrine, Organization, Training, Material, 
Eeadership and Education, Personnel and Eacilities 

DS 

direct support 

BMW 

Expeditionary Maneuver Warfare 

EP 

emergency preparedness 

ESG 

Expeditionary Strike Group 

EWTGLANT 

Expeditionary Warfare Training Group Atlantie 

EAC 

forward air controller 

EBI 

Eederal Bureau of Investigation 

ECS 

Euture Combat Systems 

EEG 

Guided Missile Erigate 

EEH 

Halifax (or City) Class Erigate (Canadian) 

EM 

field manual 

EOB 

forward operating base 

ERAGO 

fragmentary order 

ESCC 

fire support coordination center 

GBS 

Global Broadeast System 

GIG 

Global Information Grid 

GISAC 

Georgia Intelligence Sharing Analysis Center 

GWOT 

Global War on Terrorism 

HED 

homeland defense 

HED CS JOC 

Homeland Defense and Civil Support Joint 
Operating Coneept 

HMCS 

Her Majesty’s Canadian Ship 

HSI 

human systems integration 

lA 

information assurance 

IM 

information management 

10 

information operations 

IRC 

Internet Relay Chat 

ISR 

intelligenee, surveillance, and reconnaissanee 

IWS 

InfoWorkSpaee 
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JCIDS 

Joint Capabilities Integration & Development 
System 

JCS-J6 

Joint Chiefs of Staff J-6 

JFC 

Joint Eunctional Concept 

JIC 

Joint Integrating Concept 

JOAF 

Joint Operations Area Eorecast 

JOC 

Joint Operational Concept 

JOpsC 

Joint Operations Concepts 

JROC 

Joint Resource Oversight Council 

JTF 

joint task force 

JV2020 

Joint Vision 2020 

KM 

knowledge management 

LFA 

lead federal agency 

LFOC 

landing force operation center 

LHD 

Amphibious Assault Ship (Multi-Purpose) 

LNO 

liaison officer 

LOE 

limited objective experiment 

LSD 

Dock Landing Ship 

LZ 

landing zone 

MAGTF 

Marine Air Ground Task Eorce 

MCCDC 

Marine Corps Combat Development Command 

MCOIN 

Maritime Command Operational Information 
Network 

MCO JOC 

Major Combat Operations Joint Operating Concept 

MEDEVAC 

medical evacuation 

MEE 

Marine Expeditionary Eorce 

METOC 

meteorological and oceanographic 

MEU (SOC) 

Marine Expeditionary Unit Special Operations 
Capable 

MIO 

maritime interdiction operation 

ML Chat 

Multi-Level Chat 

MOPP 

mission oriented protective posture 

MS Chat 

Microsoft Chat 

MSPE 

maritime special purpose force 

NC JEC 

Net-centric Joint Eunctional Concept 

NC JIC 

Net-centric Joint Integrating Concept 

NCES 

Net-Centric Enterprise Services 

NCP 

Navy Capability Pillar 

NETCOM 

Network Enterprise Technology Command (US 
Army) 

NETWARCOM 

Naval Network Warfare Command 

NIPRNET 

non-secure internet protocol routed network 

NPS 

Naval Postgraduate School 

NRC 

National Response Center 

OAG 

operational advisory group 

ODA 

operational detachment-Alpha 
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OEF 

Operation ENDURING FREEDOM 

OEO 

Other Expeditionary Operations 

OGA 

other government agency 

OIE 

Operation IRAQI FREEDOM 

OMETS 

Operational Maneuver From The Sea 

OODA 

observe, orient, decide, act 

OPNAV 

Office of the Ghief of Naval Operations 

OWS 

Operational Weather Squadron 

P2P 

peer to peer 

PAG 

Public Affairs Group 

PHIBGRU 

Amphibious Group 

PHIBRON 

Amphibious Squadron 

PUC 

personnel under control (not a POW) 

PWR 

Persistent War Room 

PACSCI 

Pacific Science & Engineering Group 

RPG 

rocket propelled grenade 

SA 

situational awareness 

SAR 

search and rescue 

SATCOM 

satellite communications 

SD JOG 

Strategic Deterrence Joint Operating Goncept 

SIPRNET 

secure internet protocol routed network 

SITREP 

situation report 

SPAWAR 

Space and Naval Warfare Gommand 

SSAA 

System Security Authorization Agreement 

SSC-SD 

SPAWAR Systems Genter San Diego 

STESG 

Sea Trial Executive Steering Group 

STOM 

Ship To Objective Maneuver 

SEE 

secure telephone equipment 

STU 

secure telephone unit 

SO JOG 

Stability Operations Joint Operating Goncept 

SOA 

Sustained Operations Ashore 

TAGG 

tactical air control center 

TAGP 

tactical air control party 

TIG 

troops in contact report 

TRADOG 

Training and Doctrine Gommand (Army) 

TRAP 

tactical recovery of aircraft and personnel 

TW04 

TRIDENT WARRIOR 04 

TW05 

TRIDENT WARRIOR 05 

UAV 

unmanned aerial vehicle 

UGG 

Universal Ghat Ghent 

USGENTAF 

US Gentral Air Forces Gommand 

USGENTGOM 

US Gentral Gommand 

USMARFORLANT 

US Marine Forces Atlantic 

USNAVGENT 

US Naval Forces Gentral Gommand 

USPAGOM 

US Pacific Gommand 

USSOUTHGOM 

US Southern Gommand 
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VBSS 

VMU 

WMD-CST 

XML 

XMPP 


visit, board, search, and seizure 

Marine Unmanned Aerial Squadron 

Weapons of Mass Destruction Civil Support Team 

Extensible Markup Language 

Extensible Messaging and Presence Protocol 
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APPENDIX B. CHAT SURVEY DEMOGRAPHICS 


US Marine Corps 


MOS 

05 

04 

03 

02 

Total 

0180: Adjutant 



1 

1 

2 

0202: MAGTF Intelligence Officer 


1 

2 


3 

0206: Signals Intelligence Officer 



2 


2 

0302: Infantry Officer 


1 

1 


2 

0303: Light-Armored Vehicle Officer 



1 


1 

0402: Logistics Officer 


1 



1 

0602: C2 Systems Officer 



3 

1 

4 

0802: Filed Artillery Officer 


3 



3 

3002: Ground Supply Officer 



1 


1 

6002: Aircraft Maintenance Officer 



1 


1 

7202: Air C2 Officer 


1 



1 

7525: Pilot VMFA 


1 



1 

7562: Pilot HMH/M/L/A 


2 



2 

7566: Pilot HMH/M/L/A 



1 


1 

7577: Weapons and Tactics Officer 



1 


1 

7588: NFO (EA-6B EWO) 



2 


2 

Total 

0 

10 

16 

2 

28 


Operational Experience 


Operation 

Tours 

ENDURING FREEDOM 

13 

ENDURING FREEDOM-PHILIPPINES 

1 

IRAQI FREEDOM -1 

16 

IRAQI FREEDOM - II 

7 

SUBSEQUENT IRAQI FREEDOM ROTATION 

2 

SOUTHERN WATCH 

3 

UPHOLD DEMOCRACY 

1 

ALLIED FORCE 

1 


Billets 

Fire Support Coordinator, 3d Marine Regiment 

S-1 (Adjutant), 3d Battalion, 3d Marine Regiment 

S-6 (C2 Officer), 3d Battalion, 3d Marine Regiment 

S-2 (Intelligence Officer), 2nd Battalion, 5th Marine Regiment 

S-6, 2nd Battalion, 5th Marine Regiment 

S-2, 6th Marine Regiment 

S-3 (Operations Officer), 3d Battalion, 6th Marine Regiment 

Rifle Company Executive Officer, 1st Battalion, 8th Marine Regiment 

S-3 A (Assistant Operations Officer), 11th Marine Regiment 

Commanding Officer Battery M, 3d Battalion, 11th Marines 

Supply Officer, 1st Combat Engineer Battalion 

Company Commander, 1st Light Armored Reconnaissance Battalion 

S-3 A, 3d Radio Battalion 

S-3, Combat Service Support Group 3 

S-3 A, Transportation Support Battalion, 1st Marine Logistics Group 

S-6, Transportation Support Battalion, 2nd Marine Logistics Group 

KC-130, Liaison Officer, 22nd Marine Expeditionary Unit (Special Operations Capable) 

S-2A (Assistant Intelligence Officer), 24th Marine Expeditionary Unit (Special Operations Capable) 
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S-6A, 24th Marine Expeditionary Unit (Special Operations Capable) 

S-3A, Marine Unmanned Aerial Vehicle Squadron 2 

Squadron Pilot, Marine Heavy Helicopter Squadron 465 

Squadron Pilot, Marine Medium Helicopter Squadron 364 

Assistant Aircraft Maintenance Officer, Marine Air Logistics Squadron 41 

Electronic Warfare Department Head, Marine Tactical Electronic Warfare Squadron (VMAQ) 4 

Aircraft Maintenance Officer HMM-265 (REIN), 31st Marine Expeditionary Unit (Special Operations 

Capable) 

Staff Secretary, 2nd Marine Aircraft Wing 

3rd Radio Battalion Detachment Officer in Charge to 11th Marine Expeditionary Unit (Special Operations 


Capable) 

TOPGUN Instructor 

US Air Force 

MOS 

05 

04 

03 

02 

Total 

11 A: C-130 Pilot 


1 



1 

12B3: Bomber Navigator 


1 



1 

14N3: Intelligence Officer 


2 

3 


5 

15W3: Weather Officer 


2 

4 

1 

7 

71 S3: Special Investigations 

Officer 



1 


1 

Total 

0 

6 

8 

1 

15 


Operational Experience 

Operation 

Tours 

ENDURING FREEDOM 

7 

IRAQI FREEDOM -1 

8 

IRAQI FREEDOM - II 

2 

SOUTHERN WATCH 

4 

PROVIDE COMFORT 

1 

SECURE TOMRROW 

1 


Billets 

13 METOC, US Southern Command 
Vance AFB 

437th Airlift Wing (Special Operations Division) 

55th Wing 

Air Force Office of Special Investigations Detachment 105 

Headquarters Air Force Space Command 

Combined Air Operations Center, A1 Udeid Air Base, Qatar 

8th Fighter Wing, Kunsan Air Base, Republic of Korea 

28th Operational Weather Squadron 

Graphics Flight Commander, USCENTAF 

11th Bomb Squadron 

HQ, 2nd Air Force 

421st Fighter Squadron 

17th Operational Weather Squadron 

C-32 (Boeing 757) Pilot, 1st Airlift Squadron 
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US Navy 


MOS 

05 

04 

03 

02 

Total 

1110: Surface Warfare Officer 



3 


3 

1310 : Helicopter Pilot 


1 



1 

1600: Information Professional 


1 



1 

1630: Intelligence 



1 


1 

6120: SWOLDO 

1 




1 

Total 

1 

2 

4 

0 

7 


Operational Experience 


Operation 

Tours 

ENDURING FREEDOM 

1 

IRAQI FREEDOM -1 

1 

JTF-Katrina 

2 


Billets 

Operations Officer (OpsO), Helicopter Anti-Submarine Squadron Three 
Fleet Information Systems Officer, Commander Third Fleet 

Command, Control, Communications, Computers, and Combat Officer (C50), USS IWO JIMA (LDH-7) 
Fire Control Officer, USS STOUT (DDG-55) 

Assistant OpsO, Amphibious Squadron Four 

Squadron Intelligence Officer, Strike Fighter Squadron (VFA) 146 

Navigator, USS CROMMELIN (FFG-37) 


US Army 


MOS 

05 

04 

03 

02 

Total 

18A: Special Forces Officer 


1 



1 

74A: Chemical Officer 


1 



1 

13A: Field Artillery Officer 



1 


1 

Total 

0 

2 

1 

0 

3 


Operational Experience 


Operation 

Tours 

ENDURING FREEDOM 

2 

IRAQI FREEDOM 

1 


Billets 

Special Forces ODA Commander, 3d Special Forces Group (Airborne) 
2nd Infantry Division, USFK, Korea 
S-4 Officer, 41st Field Artillery Brigade 
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COALITION 


Country/Service 

05 

04 

03 

02 

Total 

Canadian Forces (Navy) 



1 


1 

New Zealand (Navy) Principle 
Warfare Officer 


2 



2 

Total 

0 

2 

1 

0 

3 


Operational Experience 


Operation 

Tours 

ALTAIR (CANADIAN OFF PARALLEL) 

1 

UNISON (CANADIAN KATRINA) 

1 


Billets 

Combat Officer, HMCS TORONTO (FFH-333) 

New Zealand Maritime Operations Staff 

Joint CIS Plans - Maritime (J65M), Head Quarters Joint Forces New Zealand 
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APPENDIX C. CHAT SURVEY EXAMPLE 


OPERATIONAL CHAT REQUIREMENTS 

Captain Bryan A. Eovito, USMC 

Joint Command, Control, Communications, Computers, and Intelligence (JC4I) 

Graduate School of Operational & Information Sciences (GSOIS) 

Naval Postgraduate School 
1 University Circle 
Monterey, CA 93943 

NIPRNET: baeovito@nps.edu 

Purpose 

This data call seeks to generate operational, user-level data concerning text-based chat 
usage. 

Instructions 


This data call has two parts: 

1. Respondent information. 

2. Twelve questions. A series of questions designed to capture respondent experience. 
When answering, use specific examples. Examples may be drawn from operational and 
exercise experiences. 

*Respondents may add additional comments, inputs, etc at the end of the document; 
however, please ensure they are clearly defined. 

Respondent Information 

1. Rank: 

2. Service (& Country): 

3. MOS (Warfare Designator): 

4. East billet and unit: 

5. Operations participated in: 
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Questions 

Respond with specific examples. Explain: 

• What chat tool(s) were used 

• What services, coalition partners, or other organizations were involved in the 
chat 

• How it affected your ability to perform the task 

• Why chat was used rather than another form of 
communication/collahoration. 

• Specify if you used chat for PLANNING, EXECUTION, or BOTH 

• Consider both operational and exercise experience 


1. Have you used chat during the Marine Corps Planning Process (MCPP) or Rapid 
Response Planning Process (R2P2)/Crisis Action Planning (CAP)? 

2. Have you used chat for target planning and/or strike execution? 

3. Have you used chat for tasking intelligence assets? Have you used chat to collect or 
disseminate intelligence? 

4. Have you used chat for operational execution (tasking, coordinating, passing 
prowords, etc)? Treat each independently and provide examples. 

5. Have you used chat for logistical planning and/or execution? 

6. Have you used chat for cross boundary coordination (same service, joint forces, or 
coalition forces)? 

7. Have you used chat for C2/C4ISR Systems Installation, Operation, and Maintenance 
(lOM) to include troubleshooting? 

8. Have you used chat to plan, request, or coordinate Search and Rescue (SAR) or 
MEDEVAC? 

9. Have you used chat to plan, task, coordinate, or execute Combat Assault Support or 
Close Air Support? 

10. Have you used chat for supporting arms coordination, fire plan development, or 
execution? 
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11. Have you used chat for planning, coordinating, or executing Civil Military 
Operations? 

12. Have you used chat for any tasks not listed here? 
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APPENDIX D. SERVICE CHAT REQUIREMENTS 

COMPARISON 


SERVICE TEXT-BASED CHAT REQUIREMENTS COMPARISON 

Requirement 

USN 

USMC 

USA 

USAF 

FUNCTIONALITY 

Participate in Multiple 
Concurrent Chat 
Sessions 

X (Tile, minimum 

10; participating is 
monitoring & 
sending; tactical 
users treat as radio) 

X (Open, join, and 
chat simultaneously) 

X 

X 

Persistent Rooms & 
Transitory Rooms 

X (Log both types; 
persistent remains 
when empty, 
transitory ends when 
last user leaves) 

X (invite to session 
on ad hoc basis; 
administrator should 
be able to promote ad 
hoc to persistent) 


X (persistent and ad 
hoc conferences) 

Room Access 
Configurable by Users 

X (Public, private, 
hidden; related to 
login overhead 
issues; assign user(s) 
as moderators) 

X (Moderator to 
control and manage 
chat sessions) 


X (admit, deny, 
remove users) 

Automatic Reconnect 
& Rejoin Rooms 

X 




Thread 

Population/Repopulati 

on 

X (User controlled, 
select portion of log 
to repopulate) 


X (catch-up feature 
for late entry) 


Private Chat 
“Whisper” 

X (Logging of these 
configurable by user) 




One-to-One IM (P2P) 




X 

User Configured 

System Alerts 

X (Keyword 
configuration; 
audio/visual alarm; 
user 

connect/disconnect) 




Suppress System 

Event Messages 

X 

(Connect/disconnect 
of users not shown in 
thread; configurable 
alerts for specific 
user 

connect/disconnect) 

X (systems events not 
in text channel but 
system control 
channel) 



Naming Conventions 
Identify Functional 
Position 

X (Functional name 
stays logged in, user 
attached changes) 

X (view identity of 
participants) 

X 


Multiple Naming 
Conventions 

X (Varies with scope 
of room) 




Multiple User Types 




X (moderator, 
participant, viewer) 


77 







Date/Time Stamp 

X (Connect, 
disconnect, 
messages) 


X 

X (For auditing) 

Chat Logging 

X (Central on server; 
user searchable) 

X (save and archive) 

X (save chat and IM 
content) 

X (For auditing) 

User Access to Chat 
Logs 

X (User searchable 
from Chat Logging) 

D (Searches and 
queries of logged 
data) 


X 

INFORMATION ASSURANCE 

Access control 




X(members-only, 
password-only, and 
invite-only) 

PKI Enabled (DOD 
CAC) 




X 

User authentication via 
Active Directory and 
LDAP ver3 




X 

Unique ID for all users 
worldwide 




X 

Provide Encryption 




X (DES, 3DES, and 
AES encryption (up 
to 256-bit)) 

Multi-Level Security 
Operation 


D 



SCALABILITY 

Austere Network 
Operation 

X (100 bps per 
user/room; tactical 
platforms <10Kbps; 
satellite latency) 

D (EPLRS; I MEF 
IRC Implementation) 

X (<5 6kbps, 
<256kbps, 

< 1024kbps) 

X(2.4 Kbps) 

Low Overhead Login 
Process 

X (lightweight 
authentication or 
optional) 




Use Client Without 
Server 

X (P2P between 
clients - SOC model) 




Distributed 

Architecture 

X (Ships have 
organic capability) 



X (operate globally & 
federated) 

# Concurrent Chat 
Sessions 

X (40 threshold) 




# Concurrent Users 

X (2000 threshold) 


X (<25, <50, <100) 

X (Single 
session=500+; 
federated=500,000+) 

Specified Quality of 
Service 

X (Response time, 
reliability, latency - 
all TBD) 




INTEROPERABILITY 

DOD Standards 

X 



X (based on 
standards by any 
recognized standards 
body) 

Multi-Platform Clients 

X (servers: Solaris, 
Linux, BSD, IBM, 



X (1. Applications 
(Win32, UNIX) 
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and Windows server 

8; elients: (WinX, 
Linux, Windows CE, 
and MaeOS) mobile 
deviees/handhelds) 



2. Applets (Java, 

VM) 

3. Web Browser- 

only) 

Interoperate with 
Existing Collaboration 
Systems 


X (188/220 interfaee 
[radio 

eommunieations] D- 
DACTs) 


X (Interoperate with 
existing USAF IM, 
Chat, and Presenee 
systems: 1. 
InfoWorkSpaee, 2. 
DCTS (Envoke), 3. 
mIRC (IRC), 

4. Sametime 
(SIMPLE)) 

Interoperate With 

Offiee Automation 

Tools 


X 




Sources: 

Banerjee, Sunoy N., and John A. Bentrup. 2002. Proposed NETWARCOM Guidance: The 
ejfective Use of Chat. Alexandria: Center for Naval Analyses. CRM D0006071. A3/Revised. 

Banerjee, Sunoy N., and John A. Bentrup. 2003. Fleet Chat Requirements. Alexandria: Center for 
Naval Analyses. CME D0008468.A1. 

Bentrup, John A., Sunoy N. Baneqee, Aaron R. Baldwin, and Carl V. Kimble. 2005. Distributed 
Internet Relay Chat Architecture. Alexandria: Center for Naval Analyses. CRM D0010253.A1/Final. 

Boetteher, Diane, SRA, Defense Information Systems Ageney. “Text-based Chat Way Ahead 
Update 28 Mareh 2005.” (Presentation at SPAWAR Systems Center 2005 IRC Chat Conferenee), San 
Diego, 8 June 2005. 

Catanzaro, Jean Ph.D. 2005. Compiled Features of Chat Client Teehnologies San Diego: Paeifie 
Seienee and Engineering Group, Ine. 

Catanzaro, Jean Ph.D., John Gwynne, Ph.D., and Craig Mitehell, Ph.D. 2005. Usability of Chat in 
the Maritime Coalition Environment: Empirical Findings from a Limited Objective Experiment for Trident 
Warrior 2005. 2005. San Diego: Paeifie Seienee and Engineering Group, Ine. 

Catanzaro, Jean Ph.D., John Gwynne, Ph.D., and Samuel Landau, Ph.D., 2005. Compiled Chat 
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APPENDIX E. SELECT COMBATANT COMMAND AND 
DEEENSE INEORMATION SYSTEMS AGENCY TEXT-BASED 
CHAT REQUIREMENTS COMPARISON 


SELECT COMBATANT COMMAND AND DEEENSE 
INEORMATION SYSTEMS AGENCY TEXT-BASED CHAT 
REQUIREMENTS COMPARISON 

Requirement 

JFCOM 

CENTCOM 

NORTHCOM 

DISA 

FUNCTIONALITY 

Participate in 

Multiple Concurrent 
Chat Sessions 

X (Monitor & 
participate) 

X (Multiple 
Simultaneous 
Chat Sessions 
Viewable) 

X (Ability to 
simultaneously 
view multiple 
rooms on monitor) 

X (Multiple Room 
View) 

Display Each Chat 
Session as Separate 
Window 

X 



X (Multiple Room 
View) 

Persistent Rooms & 
Transitory Rooms 



X (Chat room 
remains in 
existence even is 
all participants 
leave) 

X (Persistent 
rooms) 

Room Access 
Configurable by 

Users 

X(users add 
users & invite 
users) 


X (Quick and easy 
for new users 
requiring 
immediate access; 
includes new user 
registration) 


Automatic 

Reconnect & Rejoin 
Rooms 




X (Reconnect) 

Thread 

Population/Repopula 

tion 


X (Ability to re¬ 
call text 
messages for a 
break in 
connectivity) 


X (Message 
history on 
command) 

One-to-One IM 
(P2P) 



X (Must provide a 
controlled text- 
based chat 
environment; tool 
should queue 
messages for 
offline users) 

X (From 

bandwidth/COCO 
M statement) 

Off-line Messaging 




X 

User Configured 
System Alerts 



X (User manually 
send targeted or 
broadcast alerts to 
other users, the tool 
should 

automatically 
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notify user based 
on eriteria that the 
user has 
determined (e.g. 
highlighted words)) 


Text Copying 

X (Copy & 
paste text from 
all 

applieations) 


X 


Text Entering 

X (Ability to 
enter original 
text) 




Text Display 

X 

(Sequentially 

& 

eontinuously 
displayed; 
intuitively 
identify text 
provider; users 
ean seroll 
through text of 
entire session) 




Text Retention in 
Workspaee 

X (Text 
remains in 
workspaee 
until removed 
by seleeted 
user(s)) 




Hyperlinks 



X(URLS 
reeognized and 
aetive within ehat 
text) 


Interrupt Sessions 

X (Session 
managers and 
admins ean 
interrupt aetive 
ehannels as 
needed 




Foreign Language 
Text Translation 

X (Text & 
data) 



X 

File Transfer 


X (File Transfer 
Capabilities) 

X 


Portal Capable 


X (Capable of 
running in a 
portal 

environment) 



Web Client 


X (Web eapable 
elient) 


X (Web/Flash 
elient) 

Presenee Awareness 



X (User ability to 
see who is online) 

X 

Naming 

Conventions 

Identify Funetional 
Position 

X 


X 
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Multiple Naming 
Conventions 

X (Identify 
user by 
date/time 
stamp, name, 
functional 
name) 


X (Role based 
users have the 
ability to “turn off’ 
role and become 
themselves or 
another role based 
name) 


Distribution Group 
Mgmt System for 
Users 

X (On/off 
feature to 
select user 
participants) 




Date/Time Stamp 

X 

X(Date/Time 
Stamp on all 
Messages) 


X 

Chat Logging 

X (RECORD; 
retrieve & 
playback) 


X (Server should 
log all chat activity 
for future retrieval) 

X (Server side 
logging) 

User Access to Chat 
Logs 

X 


X (Searchable; 
User optional 
logging of chat 
activity in 
monitored 
channels) 


INFORMATION ASSURANCE 

Access control 


X (Use Active 
Directory for 
authentication) 

X (Secure single 
sign-on and 
seamless user 
authentication 

X (XMPP) 

Provide Encryption 



X (integration with 
industry standard 
SSL encryption) 

X (XMPP) 

Network Security 
Tools 


X (Meet current 
security 
requirements) 

X (compatibility 
with firewalls and 
proxy servers) 


Cross Security 
Domain 

Functionality 


X (Capable of 
sending 
messages 
between 
different 
networks of 
various security) 

X 


SCALABILITY 

Austere Network 
Operation 


X (Useable by 
low bandwidth 
users) 


X (Low-bandwidth 
Chat/IM capability 
identified by 
COCOMs as 
lowest common 
denominator, 
“gotta have” 
collaboration 
service 

INTEROPERABILITY 
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DOD Standards 



X (Interoperable 
with approved 
DOD network 
configurations and 
applications - 
Plug-n-Play) 


Open Standard 




X (Open protocol; 
industry support; 
future 

development) 

Multi-Platform 

Clients 



X (User accessible 
on any device; 
requires no client- 
software download; 
works with 
multiple client 
platforms; allows 
easy 

communication 
across the same 
system 


Interoperate with 
Existing 

Collaboration 

Systems 


X (Interoperable 
with Current 
Chat 

Infrastructure - 
Native or Bridge 
Capable) 

X (Must allow 
communication 
with mission 
partners (i.e. 
DHS)) 

X 


Sources: 


Boettcher, Diane, SRA, Defense Information Systems Agency. “Text-based Chat Way Ahead 
Update 28 March 2005.” (Presentation at SPAWAR Systems Center 2005 IRC Chat Conference), San 
Diego, 8 June 2005. 

U.S. Joint Forces Command. Standing Joint Force Headquarters Directorate and the Collaboration 
Information Environment Management Office. “Collaboration Requirements United States Joint Forces 
Command (DRAFT).” 2005. Norfolk: U.S. Joint Forces Command. 

Defense Information Systems Agency. “Next Generation Collaboration Service - Pilot Project 
Plan 21 January.” Available online; Internet; accessed 15 Oct 2005. 

Moore, Mr. Douglas R., CCJ6-DXC Contractor, EMIT. “United States Central Command (US 
CENTCOM) Text Chat Capabilities.” 2005. (Presentation at SPAWAR Systems Center 2005 IRC Chat 
Conference), San Diego, 8 June 2005. 

Ritchie, Mr. Jody, Collaboration Project Lead. 2005. “NORAD-USNORTHCOM (N-NC) 
Synchronous Collaboration.” (Presentation at SPAWAR Systems Center 2005 IRC Chat Conference), San 
Diego, 7 June 2005. 

U.S. Northern Command and North American Aerospace Defense Command. “NIPRNET 
Enterprise Chat Solution (DRAFT).” 2006. IT Request Number: 05-0946. 
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APPENDIX F. TRIDENT WARRIOR 05 MARITIME CHAT 

REQUIREMENTS 


TRIDENT WARRIOR 05 Maritime Chat Requirements (From: Steers 2006a) 


Text Chat Requirements By Category 

Shall Should Notes 

I. DOD/Industry Standardization 

Open Standard 

X 

Open Architecture 

X 

Service Oriented Architecture 

X 

II. Security 

Comply with current DOD security 
requirements 

Comply with DOD IT Standards 
Registry (DISR) 

X 

X 

III. Communications Scalability 



Operate in Ethernet, UHF and HE 
communieations mediums 
Eow Bandwidth 
Eow Data Rate 
High Eatency 

Operate globally in a federated network 
Operate on local, disconnected, and 
closed network 

Support Cross Domain or Multi- 
National solution 

Support Distributed Server Architecture 
Support UNIX and Windows 
interoperability 

Tank chat tool functionality to 
bandwidth availability 

Accommodate not less than 1000+ 
participants per chat session 


X 


X 


X 


X 


X 


X 

Tactical environment 


Must support CDS or Multi- 

X 

National Information Sharing 
solution 

X 


X 



Maintain core text chat 
^ capability at very low 

bandwidth levels (less than 2.4 
Kbps) 

X 
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Should accommodate 
functionality, but not at the 

Instant Messaging (IM) capable X expense of maintaining a text 

communication capability at 
low bandwidth requirement. 
Should accommodate 
functionality, but not at the 

Voiee over IP (VoIP) ehat capable X expense of maintaining a text 

communieation capability at 
low bandwidth requirement. 


IV. Communications Disruptions 

Intermittent Conneetivity - support 
multiple server disconnects 

X 

Default value can be modified 

Limited number of reeonneet attempts 

X 

by operator up to a 
predetermined maximum 

Selectable interval (time) for 
reeonnection attempt 

X 

Provides tactical functionality 

Chat tool is operable after 
communications disruption and sends 
text upon reconnection 

X 


V. Functionality 


Time stamp messages 
Date stamp messages 
Time stamp members joining and 
leaving rooms 

Date stamp members joining and 
leaving rooms 

Automatie download of logs on joining 
(pre-fill chat rooms with past messages) 
Maintain chat history during network 
outages 

Maintain screen eontents upon 
reeonnect 

Support visual alerts 
Support audio alerts 


X 

X 

X 

X 

X 

X 

X 

X 

X 


Quantity of pre-fill is seleetable 
by operator 


Visual and/or Audio notifieation of 
communieation interruption to operator 
Chat Client remains operable during 
communications interruption 
Automatic rejoining of chat rooms upon 
communications restoration 
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Alert operator for new messages 

Provide audio/visual alerts to operator 

X 

X 


for selected key words 

Ability to "cut and paste" text between 
multiple chat rooms 

X 




Support varying font size, font type, 
style (bold, italics) and color 


X 

Font Size (from 9 to 20), type 
(Ariel, Times New Roman or 
Courier New). 

Operator selectable (on / off) 

Viewing of member entry / exit 


X 

configuration to reduce screen 
clutter 

Messages can be transmitted by hitting 
"Enter" key in addition to clicking 
"Send" button with mouse 

X 



VI. Chat Sessions / Rooms 

Public chat rooms 

X 


Users must be able to freely 
enter vice "invite only" 

Private chat rooms 


X 


Permanent rooms (functional) 

X 


Rooms need to remain when 
users disconnect 

Temporary rooms 


X 

Rooms dissolve after last 
member leaves 

Limit access to private chat rooms 

Allow user to join or leave chat room at 
will 

Monitor multiple chat rooms 

Participate in multiple chat rooms 

X 

X 

X 

X 

Not less than 10 

simultaneously 


Operator selectable 


Visual "tiling" of multiple chat rooms 

X 


configuration, not less than 10 




rooms 

Resize chat room windows 

X 



Support multiple layouts of chat rooms 
(tabbed, tiled, etc) 


X 


Ability to search for chat rooms within a 
certain category 


X 


VII. Logging / Archiving 

Automatic logging 

X 


Logging is not optional at 
server or workstation 


Log all (server & room) messages at ^ 

server 

Log publie chat room conversations X 

Log private chat room conversations X 
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Log permanent chat room conversation 

X 


Log temporary chat room conversation 

X 


Automatic sending of stored chat upon 

X 


communications restoration 

Logs are retrievable 

X 

Logs are searchable 


X 


VIII. User Login and Identification 

Streamline login proeess X 

Configure to startup ehat elient 
automatieally upon login/reboot 
Configure to automatically join a user 
specified set of chat rooms upon login 

Support the use of functional title 

(IKETAO) and user name (LCDR John X 

Smith) 


Lowest possible connection 
overhead 

X Selectable by operator 

X 

For Permanent rooms provide 
the ability for watchstanders to 
change name with function 
without having to log out and 
in. This maintains continuity of 
chat session 
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